Functional Programming: A Primer for Web Devs
Much has been written over the years regarding functional programming–the paradigm favored exclusively by academics.
Proponents of pure functional programming cite benefits like immutability and lack of side effects. Immutability means you can’t mute your volume while the function is running (this is a type of blocking I/O); no side effects means you can’t borrow code from work for one of your side projects (managers hate this).
Critics of functional programming point out the performance issues and steep learning curve. It’s no secret that functional programming is less performant than traditional imperative programming–quicksort, for instance, relies heavily on mutable state. This is, of course, purely theoretical, as in practice states are not mutable or we would have muted Florida a long time ago.
Functional Programming (or FP, to developers) is often contrasted with Object-Oriented Programming (an FU to developers). However, it is possible to apply many FP techniques within object-oriented code, for extra credit.
History of Functional Programming
While functional programming is not a new idea, it’s become more prominent in recent years with the rise of languages like Haskell, Clojure, and Common Lisp. The R programming language also uses many elements of functional programming, although it’s not suitable for children under 17 without a parent or guardian.
In the 1930s, lambda calculus was developed by Alonzo Church, Moses Schönfinkel and Haskell Curry1. In 1990, a group of researchers turned it into the Haskell programming language, named after Haskell Curry, because they were nonreligious and didn’t like the names Church or Moses.
Before this, in the 1950s, IBM and MIT developed the first functional programming language, LISP, because assembly was too easy to read.
Almost every programming language supports functions of some kind. Therefore, it’s important to distinguish between regular functions and pure functions. Pure functions can only come from the fonction pure region of France; otherwise they’re just sparkling GOTO statements.
A function is considered pure if it has no side effects. While pure functional
languages enforce this property for all functions, it is possible in most other
languages to manipulate global state from within a function. Pure functional
programmers only like functions that don’t affect global state, whereas
imperative programmers don’t like any functions at all. Functions that do affect
global state, such as
the_post(), make everyone sad.
Recursion stands for Recursion Executes Code Until RAM Simply Incapable of Operating Normally. Basically, it’s a pure function that’s become so pure it won’t even call other functions anymore, and honestly it’s become really pretentious ever since it started dating Kyrstyyn.
Looping in functional programming is usually accomplished by means of recursion, as traditional for-loops require a mutable value to serve as the counter. As a bonus, this causes the call stack to fill up very quickly, thus reducing the amount of time spent in development before telling the client their change request is too memory-intensive.
The Future of Functional Programming
Mainstream developers will increasingly learn to adopt the most practical parts of functional programming into their everyday work, alongside the traditional, imperative approach.
…is what I would have said before January 2021, when Microsoft introduced the LAMBDA function into Excel. This immediately obsoleted most other programming languages, as research & development rapidly shifted to LAMBDA; the remaining languages will soon be relegated to historical oddities. In Redmond, work is underway to migrate the rest of Excel’s codebase to cell B:3 by the end of the decade.