Practical Functional Programming

Steven Heidel
7 min readNov 6, 2017

The following is reformatted from a presentation I gave at LinkedIn last year.
The presentation attempted to explain functional programming without using concepts like “monads” or “immutability” or “side effects”. Instead it focuses on how thinking about
composition can make you a better programmer, regardless of what language you use.

40 years ago, on October 17th, 1977, the Turing Award was presented to John Backus for his contribution to the design of high-level programming systems, most notably the Fortran programming language. All Turing Award winners are given the opportunity to present a lecture on a topic of their choice during the year in which they receive the award. As the creator of the Fortran programming language, one may have expected Backus to lecture on the benefits of Fortran and future developments in the language. Instead, he gave a lecture entitled Can programming be liberated from the Von Neumann style? in which he criticized some of the mainstream languages of the day, including Fortran, for their shortcomings. He also proposed an alternative: a functional style of programming.

The lecture contrasts conventional programs and their “inability to effectively use powerful combining forms” with functional programs which are “founded on the use of combining forms.” Functional programming has received renewed interest in the past several years due to the rise of highly scalable and parallel computing. But the main benefit of functional programming is one that can be realized regardless of if your program is going to be parallelized or not: functional programming is better at composition.

Composition is the ability to assemble complex behavior by aggregating simple pieces. In computer science classes much emphasis is put on abstraction: taking a large problem and splitting it up into tractable pieces. Less emphasis is put on the reverse: once you have the small pieces implemented then how do you connect them together. It seems that some functions and systems are easy to connect together whereas others are much messier. But we need to take a step back and ask: what properties of these functions and systems make them easy to compose? What properties make them hard to compose? After you’ve read through enough code the pattern starts to emerge, and this pattern is the key to…

--

--