Over a million developers have joined DZone.
Platinum Partner

Why functional programming doesn't catch on

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

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.

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

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


Published at DZone with permission of Ivo Wever .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}