Why you should learn Functional programming

My first program was written in BASIC on an IBM PC Jr and featured GOTO lines. Times were tough in the days when you used cartridges to load programs.

My first real programming job used Perl (and vim as our IDE), and after that played out, I started doing freelance web development and that meant writing a lot of PHP. Boatloads of it. Following that were professional stints with Python, Node, and Ruby. I was able to bounce between these languages pretty easily because all of them felt the same and the web frameworks mostly had the same basic pieces. Syntax aside, they mostly worked the same way. If you can take apart a Chevy you can take apart a Ford.

Things were a bit frustrating, however, because even though the similarities outweighed the differences, certain conventions were idiomatic in one language, but sneeringly verboten in another. Try using dependency injection in Ruby, or monkey-patching in PHP, for example.

And then there was the albatross of design patterns: every good software student should learn them, but on most teams I worked on, they were rarely used, poorly understood, or adapted in ways that made them scarcely recognizable. Whatever time these supposedly saved was lost due to the arguments they caused. Pretty much all the codebases I saw were like leaking boats, and nothing could keep out the constant seepage of mediocre contributions and the never ending operation of bilge pumps keeping those boats afloat.

When I finally reached for something new, it was Elixir, a functional language, and it renewed my interest in software development in a way that is hard to express. It was a huge relief to have top-notch tooling (why the Python people tolerate pip or the imprecision of Anaconda packages is beyond me), and of course there was the allure of having blazing fast performance, but it was the fundamental mental shift that functional programming offers that really made me breathe a sigh of relief.

Here are a few things that functional languages have to offer:

1. Functional languages do not obfuscate what they are doing. If you go deep enough into them, all languages are functional, however some hide this truth from their users. Why do we have to plumb the depths of some magical black box in order to understand what our code is doing?
2. Functional languages are easier to test. There is no notion of global scope or spooky action at a distance, you simply have your function, feed it input, then assert that it returns the expected output.
3. Functional languages do not rely on esoteric design patterns. Once you dig into map and reduce functions, you realize these help solve some of the fundamental problems of your code with some bare-metal tools.
4. Functional languages do not rely on shifting contexts. With over 20 years of development experience, I can testify that most of the errors I have seen in Object-Oriented code had something to do with code that would use a functional approach in some parts, and rely on inheritance and classes in another. Confusion and errors inevitably followed. You can simplify your life by removing all the non-functional concerns.
5. Learning functional paradigms makes you a better developer. Even if you don’t jump ship and rush to take up a functional language, understanding the patterns that they offer will make you a better coder. I have shuddered while looking back at how I solved particular problems in an Object-Oriented language; frequently I recognized that the solution could be solved cleanly and eloquently had I only known of some functional approaches to these problems.

Stay functional!