Why Functional Programming Matters

1989/1990 must have been a fairly dark time to be a functional programmer. Object-oriented programming was rising in prominence and the dream that industry would pay attention to functional programming looked like it was getting further away, not closer. What a time then to publish “Why Functional Programming Matters,” John Hughes’ powerful argument for why the mainstream might be making a mistake in ignoring functional programming. You can almost hear the lone voice in the corner saying “hey, over here!”

This paper is an attempt to demonstrate to the larger community (of non-functional) programmers the significance of functional programming, and also to help functional programmers exploit its advantages to the full by making it clear what those advantages are.

The version of the paper I’m referencing runs to 23 pages, but the bulk of that is examples illustrating the author’s points. The central argument itself is fairly concise, and most gloriously argued, and tying in with a theme we’ve been bouncing around over the last week or so, it all comes back to modularity. You’ll have to forgive me for extensive quoting from the opening sections of the paper today, Hughes’ prose is just too good not to!

It is now generally accepted that modular design is the key to successful programming… However, there is a very important point that is often missed. When writing a modular program to solve a problem, one first divides the problem into subproblems, then solves the subproblems, and finally combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language.

But we’re getting ahead of ourselves… When most people sum up the advantages of functional programming argues Hughes, they talk about the fact that functional programs are side-effect free and contain no assignment statements. Expressions can therefore be evaluated at any time and replaced by their values, and vice-versa – programs are “referentially transparent.” People still talk a lot about the value of immutability and side-effect free computing today, and of course these things have value. Yet it’s not a good way to explain FP to non-believers says Hughes:

Such a catalogue of “advantages” is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming isn’t (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing.

Oh, but there are benefits says the functional programmer, functional programs are an order of magnitude shorter and therefore functional programmers are more productive.

Yet why should this be? The only faintly plausible reason one can suggest on the basis of these “advantages” is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted” This is plainly ridiculous. If omitting assignment statements brought such enormous benefits then FORTRAN programmers would have been doing it for twenty years.

If this characterization of functional programming is inadequate, what is it that can both explain the power of functional programming and also give a clear indication of what the functional programmer should strive towards. Think back to the time when structured programming was new (you remember that right?) the advantages says Hughes were summed up more or less as “structured programs contain no goto statements.” This is similar to the negative ‘advantages’ advocated for functional programming.

full Article: https://blog.acolyer.org/2016/09/14/why-functional-programming-matters/