Thursday, February 26, 2009

Justification for Functional Programming

It appears that this subject has caught fire in recent years. The interest in St. Louis has resulting in the Lamdba Lounge started by Alex Miller. (Great name by the way). I have started reading (but not finished) Programming Clojure by Stuart Halloway and Programming Scala by Venkat Subramaniam. Additionally I just finshed writing a 10 page article on an introduction to functional programming, which includes 4-5 page on F#. The article is for NFJS who holds the exclusive rights at this time, but I plan to provide a link to it or post it here in its entirity after 90 days.

I should point out that I am no expert in this space, but I have been developing professional for 15+ years with a variety of languages (C, C++, Java, C#, a little Ruby, Perl, Groovy). In the last 6 months I've been "playing" with Scala, Clojure and F#.

The reason for this post is this: This article has been sent to me a couple of times and has been on twitter several. At this point I will make public comments I made in an email response regarding this subject. The first two subjects were points made via email, which make sense to maintain for this blog post.

The Argument to have UI and DB Support
I don't get the ui / db argument. This indicates an all or nothing mentality, which I would hope the industry could get over. A griffon front-end to a java hibernate db access and clojure rules engine make sense to me. Many of the functional languages provide the ability to produce a UI or interact with the DB, however that isn't really important to me as you will see below, but there are good solutions out there where this isn't really a concern.

Functional Notations and Code Beauty
I may be in the minority... but I could care less for "beauty" of code, I'm interested in less code that adds the same or more value. FP adds several notations that provide a conciseness to code, which is a huge value add. As I was writing up an article on F#... I became frustrated with my other programming languages... for instance: why is a switch in Java/Groovy so limiting. Groovy makes it better... but it is still limiting as you compare it to discriminated unions and pattern matching F#.

Getting Functional Programming
People don't get it yet (referring to the nah sayers)... they are in the battle pits and are lacking the big picture vision. This year quad core laptops are expected to be more common. That trend isn't going to stop. The last decade was all about die size and memory. This next decade is all about cores. The need for concurrency tools is a must. The language trend may be slightly ahead of its time.

I'll post more on this subject in the future... I just felt it necessary to provide some response to the value of functional programming. Frankly I've barely scratch the surface of the value.


Brian Sletten said...

Good write up, Ken. The same pressures drove the design of NetKernel to support a functional model with similar results (cleanliness, concurrency, scalability, etc.).

Anthony said...

Hi Ken,

Just curious re: The Argument to have UI and DB Support and the suggested polyglot approach...

How do you prefer these different app layers to interact? RESTful web service? Language-level bindings? Something in between? What makes sense to you?


Ken Sipe said...


I hate to give the consult answer :) but it really depends. I would say that it should be as efficient and simple as possible. Language-level does make the most sense to me in a number of cases. F# is really fantastic. It provides the ability to tie in very easily with C# and all it brings to the table. I see the same thing for Scala and Clojure on the JVM with Java. I was recently challenged by Jeff Brown to put up or shut up (he didn't actually say those exact words), and put a griffon, clojure and hibernate example up on github. I think it is a great idea.

Refocusing on your question... I really think you have to justify the need to serialize data (HTTP as an example) You don't want to lose all your efficiency gains on marshaling.

.Net for years has touted the multi-language support and rarely do shops take advantage of that. Most of them choose a language (C#) and that is the type of shop they are. It is time to move past that model. .Net and the JVM both support many... many languages. We as practitioners need to start using the right tool for the job. I wouldn't use F# for GUI code... why would I use C# for sequence, high concurrency or workflow needs if there is a better choice?

Zenchukovskiy said...

This is a very good article for my job. I didn't know what to answer to my boss. I should read it one more time to remember some phrases. I can also use it for my studies. I'm gonna custom essay paper, but still I like to find something interesting by myself.