Why functional programming doesn't catch on
Authorities in the field of software engineering have long lamented the
fact that functional programming (FP) doesn't seem to catch on. Their
sympathizers often blame that on shortcomings in the audience or their
pointy-haired bosses, but that is the easy way out: to assume that
someone that disagrees with you simply lacks the ability to understand
you is a way of shielding yourself from the possiblity that you are the
one with a shortcoming: the inability to provide a proper explanation.
I think that the actual reason for the limited adoption of FP languages
is exactly that: the way the advantages are formulated and exemplified
are completely obvious and compelling to their proponents, but those
same explanations and examples utterly fail to convince most software
engineers, because they simply do not appeal to the problems they are confronted with in their daily line of work.
I think this hypothesis is best exemplified by the seminal paper Why Functional Programming Matters. This paper sets out to:
[..] demonstrate to the 'real world' that functional programming is vitally important,
[..]
[listing of advantages]
Such a catalogue of 'advantages' is all very well, but one must not be surprised if outsiders don't take it too seriously.
[..]
We must must find something to put in its place - something which not only explains the power of functional programming, but also gives a clear indication of what the functional programmer should strive towards.
and then goes on with explanations like:
The definition of reduce can be derived just by parameterising the definition of sum, giving
(reduce f x) nil = x
(reduce f x) (cons a l) = f a ((reduce f x) l)
and applications to things like the Newton-Raphson approximation and tree pruning in artifical intelligence.
[I'm inserting an intentional dramatic silence here, in which you can see my facial expression turn to complete astonishment]
Now how in heavens name can one expect to convince the average software
engineer of the tenets of functional programming with these kinds of
examples? If it does one thing, it is scaring people away by seeming
unnecessarily difficult and academic.
Every introduction to a programming language shows you the recursive
method to calculate Fibonacci numbers. It's abstract, many people do
not relate to it very well, but it's only a single example. However,
the documentation for FP languages seem to consist solely of these
kinds of highly mathematically inspired examples. No 'Address' class to
be found there. Hasn't anyone written a functional equivalent of the
Pet Store application to demonstrate the power of FP for the regular
work that most of us do?
People that want to improve the world often overlook one fundamental
problem: you cannot improve the world just by being right. You need to
convince others of that fact if you want to exert influence. If you
cannot convince them, find out why you cannot convince them. I think
there is a bright future ahead for functional programming, as soon as
someone stands up to convince the masses.
Update:
As not everyone reads the comments, I would like to highlight a few points made there:
- The article I quote is 25 years old and was directed to people in academia. It would not be fair to conclude that all FP documentation is that hard to understand for someone without an academic background.
- There are deliberate attempts at displaying the 'real life' value of FP, for instance in Real World Haskell and Practical Common Lisp.
- Several people assert that FP is catching on, but it just isn't very visible (yet). This may be because those that use it consider it a competative advantage
- Login or register to post comments
- 8693 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Bora Ertung replied on Fri, 2009/02/27 - 10:37am
FP is still used heavily where it applies well although I really doubt it would be as popular as it was in 1980s (Symbolics anyone). On the other hand, a talented LISP programmer is very rare these days. Because of that, I would not think of putting it in my designs even if it would fit the job.
Ricky Clarkson replied on Thu, 2009/02/26 - 5:29pm
JeffS replied on Thu, 2009/02/26 - 7:45pm
For me, from what I've seen of FP, it looks interesting, and potentially powerful, and can potentially make code more concise.
But I've never been able to wrap my head around the real benefits of FP, and the ROI I'd get in putting in the effort into really mastering FP.
I'm at the point now where I need to have real benefit, and ROI, before I invest in a new technique, paradigm, or technology. I don't care about hype.
As it already stands, Programmers have a lot of mental gymnastics to go through to be able to get their heads around all the various programming paradigms - procedural, OOP, AOP, Generic programming, etc. Heck, it takes a lot of time and practice to get truly good at object oriented design, then add on top of that stuff like AOP and generics, and now FP.
I'm not saying it can't be done, or it's too hard, or whatever. I'm just saying "show me the benefits", which need to be fairly substantial, before spouting off that this is the next great thing.
Until then, I file FP under "interesting".
Rick Hightower replied on Thu, 2009/02/26 - 9:03pm
RE: "But generally, an academic paper written for academics before blogs existed shouldn't be scored the same as an unacademic blog post written for programmers with no attention span or experience of non-C-syntax languages."
I think the point is let's get it out of just the realm of academcis and describe FP in terms of ROI and feel free to dumb it down to problems that practioneers actually work-on on a daily basis. I think FP authors in general are starting to do this. There is a lot of work to be done.
The attitude that Ricky is conveying, to me, is exactly why FP has not (yet) made it to the mainstream. Let's insult the main stream developers. Fine, but who is going to let you play with your toys in their playground. C-syntax owns the world.
Rod Johnson et al brought AOP mainstream by demonstrating the benefit and building the tools and libraries with it that developer could use on their projects. They took AOP out of the realm of academics and into the Enterprise. Who is going to do this for FP?
To me, Jeff S is spot on. Well said Jeff S.
Now I digress.....
I just wrote an article on closures for groovy.dzone.com and Ken Sipe reviewed and shared an article he wrote on Functional Programming, which I then borrowed some ideas from which I covered in the last section (with some quotes and code snippets from Ken).
Ken Sipe's article is an excellent article on FP that introduces FP concepts. (Not public yet so.... you will have to wait)
Personally I think FP style programming will slowly become more mainstream as language features are slowly added to mainstream languages. In a way, it has already started happening.
That said, I look forward to the new book from the pragmatic series on Clojure from Stuart Halloway.
And reports of FP mass adoption are mostly fantasy.
See comments under Ted Neward predictions for more on this.
Ricky Clarkson replied on Mon, 2009/03/02 - 3:45am
"The attitude that Ricky is conveying, to me, is exactly why FP has not (yet) made it to the mainstream. Let's insult the main stream developers. Fine, but who is going to let you play with your toys in their playground. C-syntax owns the world."
Microsoft lets us play with our toys in their playground. C# has linq, which is strongly related to Haskell's do-notation (oh, and Microsoft Research's Simon Peyton-Jones is the lead developer of the main Haskell compiler, ghc).
C syntax is great for the things it's great at, but not very useful for side-effect free programming, which is why it needs an overhaul. There are a few options that I can think of - 1) replace the syntax completely (Haskell) 2) augment it with useful stuff (C#, Scala) 3) do nothing to the syntax, but make it possible to alter the meaning of the semi-colon, so that C syntax can mean something else.
Right now I'm in favour of the second option. C syntax may be almost ubiquitous, but it's only a syntax. It doesn't have to be the lingua franca forever.
Also, it's stupid to compare Groovy jobs to Scala jobs to prove that FP is going nowhere. Scala isn't a functional language, and it has other goals than jobs. Try looking at Haskell, ML (including Ocaml and F#) for actual languages that are FP. But the language doesn't have to be a functional one for it to benefit from functional programming. Take a look at javac's source code sometime.
Ricky Clarkson replied on Mon, 2009/03/02 - 3:56am
"Also, it's stupid to compare Groovy jobs to Scala jobs"
By this I meant intentionally stupid (a friend of mine would say 'intellectually dishonest'), rather than that the commenter has a low IQ.
Dominique De Vito replied on Mon, 2009/03/02 - 8:41am
You don't need to choose a language supporting only one paradigm, like, here, functional programming (FP).
There are many languages out there that are supporting multiple programming paradigms, like OCaml, for example (imperative+modular+functional), or F# (the OCaml-clone from Microsoft).
Then, the funny thing is that, functional programming (FP) is going to catch on, but as a side effect ;-)
Indeed, the FP is going more mainstream as FP language features are added to mainstream languages.
Then, some have written an article like Is C# becoming a functional language?
FP is also taking advantage from Paradigm based Polyglot Programming and people are been more keen to test and adop, nowadays, more exotic programming languages like Groovy, Scala, Ruby, etc. to use the right language for the right job. Then, people will be less afraid about FP.
I wrote about it 2 posts in the past.
I have tried in 2005 to sketch here the overall move of Java, C#, their future and the relationships with functional languages. This sketch is still online with reality. It give also hints about multi-core perspective and the Java/C# move to functional languages. Yes, this post is from 2005, then things are moving slowly, but without doubt, I think FP will be part of next paradigm move. Just think about OCaml being (recently) cloned by Microsoft into F#.
And into another post, more ramblings on programming languages, I have tried too to give more thoughts about this move, and reasons why such "exotic" languages, like functional languages, have NO intrinsic performance problems.
vkelman replied on Mon, 2009/05/04 - 5:24pm
Yes, LINQ (C#) definitely follows functional approach and it's already extremely populare on .NET platform. Look for articles by many propminent MS and ALT.NET developers - everything is based on LINQ (not on LINQ to SQL, but on LINQ as a functional addition to C#: lambdas, closures, higher-order functions). So, in a form of LINQ, functional programming already gained major momentum in .NET world. I'm a regular Web application application developer, but in my practical every-day work I see huge advantages which was brought by FP to C#. And I use them.
I don't know much about Java world (except studying excellent Scala), but it seems to me that .NET went ahead here. Apparently, MS care less about backward compatibility...