About Functional Programming

Why Functional Programming?

After reading articles, books, and watching videos by Eric Eliott, Brian Lonsdorf, Michael Fogus, Brian Beckman, and others, I’ve convinced myself about the following facts:

  • You usually have to make decisions about that rigid structure at a development stage where you simply don’t have all the relevant information. Requirements change with time and rigid structures don’t like changes.
  • It’s almost impossible to design a very good OOD or RDB from the very beginning because humans cannot predict the future.

Fight complexity

As Brian Beckman said, today in the software development community, we’re out of control in the complexity space. The way to control complexity is compositionality.

First Steps

Basic and easy stuff first, please. The series on functional programming in JavaScript by MPJ is a great starting point. If you never heard of high order functions, Map, Reduce, Currying, and some other related concepts, you can find a quick and fun introduction here.

I Want More of This

After convincing myself of the convenience of functions like Map and Reduce, I wanted to learn more. I found two very interesting books about functional programming with JavaScript:

  • Professor Frisby’s Mostly Adequate Guide to Functional Programming, by Brian Lonsdorf (AKA Dr. Boolean). It’s not finished yet but, hey! it’s free!!. It shows a way to develop JavaScript that, in my humble opinion, is closer to what you might expect when working with more purely functional oriented programming languages, like Scala or even Haskell. It’s related to the three videos series Classroom Coding with Prof. Frisby (very interesting too, but also very dense. You might need to watch them twice to get all the concepts). You can also find many other interesting talks on youtube from this author.

A Bit More Advanced

Brian Beckman: Don’t fear the Monad. Brian Beckman (Princeton University, Microsoft, Amazon…) gives you a glimpse of the category theory behind monoids and monads, expressed in practical terms, familiar to an imperative programmer (he also gives C# examples). I find particularly interesting the following ideas:

  • A short story about the two separated camps created when computing started: the imperative one (a tradition that led to languages like Fortran, C, Pascal, Java, etc.), where Math theory was put aside and performance was king, and the functional one (this one led to languages like Algol, Lisp, Smalltalk or Haskell), where they started with Math theory (lambda calculus) and went from there down to the machine, sometimes at the expense of performance.
  • Build complexity out of simplicity by composing functions, not by adding ad-hoc features.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store