Discussion on: Explain functional programming paradigm Like I'm Five

[Jacek Złydach]

(I'm assuming that as a 5yo, you know at least basic programming concepts)

The core and most important concept of functional programming is that of a pure function. A function is pure when its return value depends only on its input arguments, and the function does not cause side effects observable elsewhere in the system. For example, a function add(a, b) { return a+b; } is a pure function. Functional programming is fundamentally about building as much of your program as you can out of such pure functions.

Pure functions have a number of benefits:

• They are easier to read and understand than "regular" functions, because their output depends only on the input arguments.
• They are easily testable, as there's no extra state to prepare, just input arguments.
• They compose well, because there's no state to manage.
• They parallelize extremely well, because there's no state to cause bugs or locking.

Trying to build a program out of pure functions drives you towards a different style than imperative/OOP approach: code written in functional style tends to be built out of transformations of data.

Think of e.g. washing the dishes. You usually wash them, then dry them, then stack them together. A functional code implementing that would look like:

function clean_dishes(dishes) {
  const washed = wash(dishes);
  const dried = dry(washed);
  const stacked = stack(dried);
  return stacked;
}

or, in short:

function wash_dishes(dishes) {
  return stack(dry(wash(dishes)));
}

This is the core concept of functional programming. Of course, you can't write your entire program using just pure functions - after all, reading data from user or printing it out are those unpure "side effects". But you can write most of your program this way.

There are more ideas that work well with this style, that you'll frequently find in functional languages.

• Closures and higher-order functions. Functional programming is really convenient only when functions are "first-class objects" - i.e. can be created at runtime and passed around like any other data type. This enables "higher-order functions", i.e. functions taking functions as argument, which opens up a lot of nice abstractions. "Mapping", "reducing", "zipping", "currying", etc. all fall under this category.
• Immutable data. Many languages will force functional style on you by disallowing in-place modifications of existing data. E.g. appending an item to a list will return a new list instead of modifying the existing one. With some trickery in language implementation, this isn't as inefficient as it sounds.
• Advanced type systems. Functional programming is fundamentally an implementation of mathematical thinking, and mathematicians like type systems and category theory :). Note that static typing is not required for functional style; Lisp essentially invented functional programming, and to this day it's a family of dynamicly-typed languages.

[Priyal Kumar]

thanks so much, <3