Kodumaro :: Lies they’ve been told you about functional programming

Released on September 27th, 2019
The shadows behind the code.

Don’t believe in programming gurus! Said that, let’s go to some definitions, and then, take a look at the lies they’ve been told.

Functional programming aims to implement the λ-calculus as a programming environment.

Functional programming (and λ-calculus) is not about using functions, nor even about quitting object orientation.

λ-calculus is about first-class and higher-order functions, and everything as a function. Of course “everything as a function” is a bit radical for the programming context (but not impossible), however every other lambda feature is reasonable to be called functional programming.

First-class function is the one which can be used as parameter or set to a slot. First-class as in “first-class citizen”, with all rights.

Higher-order function is that which takes another one as parameter.

Besides, there are some constraints that define the functional paradigm:

  • Pure functions: functions cannot have side effects.
  • Tail-call optimisation: the last function call inside a function must replace the current stack. It prevents stack overflow when doing recursions.
  • Recursion: a function can call itself, loading a new stack.
  • Determinism: the functions must be idempotent, that means, given the same params, you shall get the same return, no matter how many times it’s called.
  • Immutability: no value can be changed. Once set it’s for good.

And there are some optional features:

  • Non-strictness: a function can be strict or lazily evaluated. On lazy evaluation, functions are called “non-strict”.
  • Typed lambda: functions (and values) can be typed by their structure or signature.
  • Free and bound variables: traditionally functions may contain bound (existent only inside stack) and free variables (got from parent context). Alternatively a functional system may forbid free variables, allowing only bound ones. Then you’ll need a fixpoint combinator for recursion.

Now that we’ve made those definitions clear, let’s talk about the misconceptions spread through the programmer’s communities – mostly by their very gurus.

(Ruby|Python|Scala|Julia) is a functional programming (⁉️)

You’ve probably heard it.

Ruby isn’t a functional programming, just as Python and Scala are not. Those are object-oriented imperative languages with one or other functional feature, but not enough to be considered even impure functional.

Julia is an impure functional language indeed, but with a lot of imperative features that disfigure its functional trait.

Functional programming is about using functions (⁉️)

When a guru says that, you can be sure he’s bullshit.

We’ve seen above what functional programming is about.

Erlang is a logic programming language (⁉️)

Logic programming is to formal logic as the functional programming to λ-calculus.

The logic programming concepts are quite different from functional programming, and deserve a whole dedicated post about. Briefly, it’s about describing the facts’ domain and querying it.

Examples of logic programming languages are Prolog, Datalog, and SQL.

Erlang’s syntax is strongly inspired on Prolog’s, but yet functional. Erlang sticks to all functional constraints and uses some logic features to provide typing, which is a functional feature too – typed lambda, you saw it just above.

Furthermore, Erlang uses the same Prolog’s syntax of defining facts to declare function signatures – not to define facts.

So Erlang isn’t a logic programming language, but a fully functional programming one.


There’s so much more about functional programming, and you should get involved. I recommend taking a look at Haskell for fully funcional programming (install GHC), and Standard ML for impure funcional programming (install MLton).


Also in Medium.

Career | Concept | Functional