Functionally Speaking

Functional programming languages, while being merely rare in academic circles, are nearly unheard of within actual production environments. This goes back to what I wrote about a few weeks ago, in that there are considerations beyond technical qualifications for choosing a particular language. But I keep really, really wanting to start slipping some functional programming into my projects. I know that I keep saying this and never do.

There is one post regarding F# that keeps haunting me.

What burns me the most is that I know that it is not just F# that is like this. Scheme, from my experience is like this. By extension, that makes Lisp like this. Where Perl gets functional language-esque, it is like this. Even SQL (shudder) is like this in many ways (think of how many lines of C++ it would take to do what 1 line of SQL does). O’Caml is like this. Ruby may be somewhat like this. From what many of the readers lately have been telling me, APL is like this.

Read that post carefully. Ninety lines of code to do all of that work! My experiences with Scheme and Perl let me know that the lines are probably not too complex either, but there may be a touch of hackishness involved. Regardless. There is one salient point to be made here folks, and it is important: the few hours that a good programmer will spend to learn a language well enough to do this can deliver ROI on the very first use of it.

This eliminates a lot of the business objections to using these types of languages completely. If the language itself takes a few hours to learn at a basic level of proficiency, has enough library support (like F# and the .Net Framework, Perl and CPAN, Lisp and many mathematical function, etc.) or can communicate with code that has good library support (via UNIX pipes, BSD sockets, COM, process forking, whatever) then we knock down a lot of barriers. Get your top programmer cranking out code in one of these nifty little languages, get it blackboxed to your presentation and database layers that your other coders are working on, and we have a development model which is actually quite realistic.

I have been meaning forever to be learning a new language. It was going to be Ruby or possibly Python, but I am fairly convinced that it should be O’Caml/F# or APL. There is a company out there (APL Next) that makes a .Net version of APL, I am going to get in touch with them and see what their system is like. I still trend towards .Net, because of the quality and comfort of Visual Studio, my existing knowledge of the .Net Framework, and the ease of building Web and desktop applications within it without getting tangled up in a lot of plumbing. I will keep you informed with my progress on this. I would love to be able to put a few more arrows in your quivers when wanting to use a better language for a task than the language that everyone already knows. I will also hopefully have a small sample app together soon to show a three tiered development approach that works without everyone on the team having to learn new things.


About Justin James

Justin James is an OutSystems MVP, architect, and developer with expertise in SaaS applications and enterprise applications.

Editor's Picks

Free Newsletters, In your Inbox