Why FP Matters - Part 1 🐘

December 13, 202012 min read


the blind men and the elephant
Image source Wikipedia

O how they cling and wrangle, some who claim

For preacher and monk the honored name!

For, quarreling, each to his view they cling.

Such folk see only one side of a thing.2


The Elephant in the Room

We're here to talk about Functional Programming (FP). This is my attempt to make sure people have a proper introduction to it. FP is like alien technology to most of us and it may not be easy to figure it out on your own. Most people that I've talked to remind me of the blind men violating the elephant's privacy to recognize the whole from the parts. We have touched and seem to recognize one aspect of this style of programming, but are not clear about what more is out there.

I'm not trying to insult anybody's intelligence here but it can make your head hurt sometimes. To those who are skeptical, please assume that the motto here is not to convert you, but to introduce you to something new. A new tool in your arsenal to address some of the problems we face while building software. If you keep an open mind, you'll be able to take in a lot more.

I intend this to be a series of articles, to make the content easier to digest. This is Part 1.

Another disclaimer - I will not try to put your favorite language down. My choice of language(s) are so because they simplify concepts. At the same time help you learn powerful techniques. Having said that, it may help you identify a few new things in your workspace which are related to FP.

  • You will be able to identify and appreciate how your language is changing or has already changed.
  • It will make you more aware of the current trends and the near future.

Why FP Matters

I've based this series of articles on a paper by the same name and it is authored by John Hughes1. There are several papers out there that talk about FP, most notably the ones by Philip Wadler, Richard Bird, and Erik Meijer.I chose this one for its simplicity. More importantly, it focusses on things that we can do rather than what we shouldn't do.

It focuses on a small area in the FP paradigm and yet manages to display some awesome power we get from it. To be specific, it talks about two features - high-order functions and lazy evaluation.

Why Functional Programming Matters, is a white paper which "... dates from 1984, and circulated as a Chalmers memo for many years. Slightly revised versions appeared in 1989 and 1990 in the Computer Journal and the Year of Programming."1

As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write, easy to debug, and provides a collection of modules that can be re-used to reduce future programming costs. Conventional languages place conceptual limits on the way problems can be modularised. Functional languages push those limits back.

-- from the Abstract of Why Functional Programming Matters

FP in the Real World

Below is the timeline of some real-world programming languages that are functional. Yes, FP was introduced before structured programming and Object-Oriented (OO).

The most popular C# and Java have been fairly recent entries. Both of those languages had sold themselves as Object-Oriented when they started and eventually adopted functional aspects.


functional programming languages timeline

FP started with the LISP family of languages. Although those languages were much ahead of their time with features like garbage collection, they were too heavy on performance for the hardware available during those times. Things have changed since back then, and we carry much more powerful computers in our pockets. FP survived within the academic circles through a series of language researchers. It regained the interest for teams that dealt with popular real-world languages since the late 90s.

  • APL has been around since 1964, Erlang 1986, OCaml is from the nineties.
  • Scala 2003, was followed by F# which came out in 2005
  • Scala was used by Twitter and LinkedIn for the very same reason. Solving concurrency issues. Scala is not the language of choice for programming with Spark 🔥
  • F# was used to run analysis on huge data obtained from Xbox Live users 🎮.
  • Erlang was developed by Ericsson and is synonymous with concurrency. Apart from Ericson, it is used by big names like Motorola, Yahoo, Amazon, T-Mobile. The more popular applications are Facebook Chat and Whatsapp 💬.
  • OCaml on which F# is based is used in many research projects at Microsoft 🧪.

.NET has borrowed a lot from the FP world and it has been well received. If you guys are using LINQ, you are doing FP.

FP has been present in the real world. But mostly it gets recognized as a new language feature. We don't bother to understand where it came from. The result is that we don't clearly understand the motivation and the power offered by this new paradigm. It mostly features as an extra in our programming skills.

Note: I haven't mentioned other popular languages not clutter the timeline. Many languages like Ruby and Python have functional aspects to them. The most notable language that I left out is the omnipresent JavaScript. It has been more functional than most languages since it's inception, but this fact was never made more popular before the early 2010s.

Problems of Software Development

A powerful programming language is more than just a means for instructing a computer to perform tasks. The language also serves as a framework within which we organize our ideas about processes

-- Structure and Interpretation of Computer Programs

... and these ideas can grow in size and complexity. As code grows, so does the importance given to its structure, modularity, extensibility, and reusability. This helps us to break down the complexity so that we can look at a portion of the system at a time. It becomes easier to write, debug, and test code.

We also want the quality to be high, ergo less number of bugs. This is a correct expectation, and most of us do due diligence to make sure high-quality standards are achieved. However, we also know from experience, that bugs are inevitable. Empirical evidence suggests that the more code we write, the higher the count of bugs. The solution should be simple, write less code. But you won't believe me if I told you that it is possible. So I will come back to this in the future.

To add to our woes, we have to now think about concurrency and parallelism.

We always want to try and build something that can be easily extended and easily maintained. We want to be able to build faster. If you build faster, you take less time. If you take less time, you cost lesser.

FP claims to help you build powerful and reusable components with less code.

From the Language Creators

About 10 years back, we began to recategorize Moore's declaration. It was less of a law and more of an observation based on historic trends. The processors were not getting faster. We had reached our limits and the hardware guys switched to increasing the number of processor cores on the chip.

This meant that all the benefits that the software developers were getting year on year due to increasing CPU clock frequencies stopped. We would need to change the way we program to make use of the multiple cores. Our plain old imperative program doesn't do well here. This is one of the major motivations for languages to change and adopt the functional style.

You can refer to the talks below by two people who play key roles in a couple of popular languages that are used in the industry. Their plea was to let programmers write more declarative code. This was so that the language compilers and runtimes could help optimizing code for the hardware.

Anders Hejlsberg Trends and Future Directions in Programming Languages (DevDays 2010 Keynote). Anders Heljsberg is a technical fellow at Microsoft and he is the Chief Architect of the C#.

Martin Odersky, "Working Hard to Keep It Simple" - OSCON Java 2011. Martin Oderskey was part of teams that designed the Scala programming language and Generic Java.



And if you don't believe these new kids on the block (I am kidding!). Below is the big daddy of high-level languages. Meet John Backus.

John Backus
Image Source Wikipedia
  • Invented Fortran (1957 – 59). It became the first widely used high-level language. Mostly imperative.
  • Published: Can Programming Be Liberated from the von. Neumann Style? (Turing Award Lecture 1978).
  • Worked on a function-level programming language known as FP.
  • His paper did less to garner interest in the FP language than to spark research into FP in general.

He realized that limiting programmers using high-level languages to just the imperative approach wasn't going to be good enough. The approach that he researched to improve things was more on the functional side.



~ ▪ ~ breathe ~ ▪ ~


What is FP?

Functional programming is so called because its fundamental operation is the application of functions to arguments. A main program itself is written as a function that receives the program’s input as its argument and delivers the program’s output as its result. Typically the main function is defined in terms of other functions, which in turn are defined in terms of still more functions, until at the bottom level the functions are language primitives.

-- Why Functional Programming Matters

Isn't that true about most of the programs that you've read and written so far? You write a function, pass it parameters as input, you get the output as a return value. If the function size grows, you break it up into smaller functions. You can keep breaking it down until you are dealing with language primitives such as strings or integers or boolean values.

The above is true, but there are a few more things that make it more interesting. I would advise you to not deep dive into defining the elephant yet. We are yet to fondle it all over.

Analogy with Structured Programming

The most important difference between structured and unstructured programs is that structured programs are designed in a modular way.

-- Why Functional Programming Matters

It is easy for a newcomer to get confused between structured programming and FP. Structured programming advocates programming without goto. Functions or procedures are treated as a single entry, single exit box. This makes programs mathematically tractable.

The more important advantages of the structured approach are that it gives us a modular design. We get re-usable components, little methods that we can plug and play with. We can test modules in isolation and not worry too much about the world.

How is it different from FP? FP provides us new ways of combining the solution parts. Hence, we can think of de-composing the solution differently. We have access to new kinds of glues - higher-order functions and lazy evaluation.

FP vs OO

FP and OO are orthogonal to each other. OO is more about code organization and managing dependencies. These are required to manage software at scale. FP provides you a separate set of tools to manage complexity and modularity. It is possible to do FP with OO.

The Chair


log chair made of a log
Picture by Alex Braga

Consider a carpenter building a chair. He can carve out a chair of a single monolithic log of wood, he can surely make it work but there is a risk and possible problems.

  • One person will need to know about all parts of the chair
  • If something fails, the whole block of wood and the time invested in building the chair will be wasted

A better way would be for us to make legs, backrest, and seat separately and then glue them together to build a chair.

Recap

We touched upon the below things

  • How FP can be beneficial for software development and how it can reduce time and cost.
  • Where FP is already present in the real world. In your world.
  • The motivations of language developers to be interested in FP
  • Finally, we compared FP with structured programming and OO.

Up Next

Why FP Matters - Part 1½ 💫 - A bit of Haskell We will acquaint ourselves of little fun bits of Haskell

then

Why FP Matters - Part 2 🎈 - Higher-order functions We will dive into the first type of glue that is higher-order functions and see how they can help modularize code. We will write small and simple generic parts to process lists. It will be a little domain-specific language. And I promise, there will be code 🙂.

For more fun posts like these, click here to see a list of all my posts.