Welcome back to my series on practical functional programming in JavaScript. This time, I'll elaborate on a core functional programming concept that causes a lot of confusion for newcomers to functional programs: data last.
For the most comfortable read, you should have knowledge of Array.prototype.map and decent programming fundamentals.
Note: I use methods from my functional programming library rubico in a couple places to illustrate my points. I link documentation where applicable.
What is data last?
Data last is a programming convention wherein the data of a procedure is provided as the last parameter. This is in contrast to data first, where the data is the first parameter - you are probably more used to seeing this one.
This is data first. Quite literally, the Array (our data) is first.
[1, 2, 3, 4, 5].map(number => number * 2) // > [2, 4, 6, 8, 10]
This is data last. The Array (our data) is now last.
map(number => number * 2)([1, 2, 3, 4, 5]) // > [2, 4, 6, 8, 10]
map in this case is a partially applied function from rubico.
Why does this matter?
Consider the program
const double = x => x * 2
const square = x => x * x
const doubleSquare = n => {
const doubled = double(n)
const squared = square(doubled)
return squared
}
doubleSquare(3) // > 36
doubleSquare here is rather hand-holdy and imperative. However, since data is last for both double and square, we can rewrite doubleSquare using the functional approach in terms of just the two functions.
const double = x => x * 2
const square = x => x * x
const doubleSquare = pipe([
double,
square,
])
doubleSquare(3) // > 36
Look ma, no variables! Data last allows us to write larger programs as compositions of smaller ones. This is a powerful concept for code reuse, and core to the functional programming paradigm. This idea is extensible at any scale; from small scripts to production workloads, anything you can represent with a function falls under this model.
I'll leave you today with a couple excerpts from the Unix philosophy:
Write programs that do one thing and do it well.
Write programs to work together.
We just discovered a powerful way for programs to work together via a simple convention: data last. Next time, we'll examine how we can consistently write programs that do one thing and do it well. Be on the lookout for Side Effects and Purity.
Edit: You can find the rest of the series on rubico's awesome resources
Oldest comments (3)
While this is a nice brief introduction, I think you should demonstrate this with some sort of partial application. That's where the ideas really shine.
Perhaps it would have been better for me to go into partial application a bit more rather than just link the docs for map. Thank you for the feedback, i'll find a way to work it in
Would you like to help me with this? I'm adding flatMap as the 24th function github.com/a-synchronous/rubico/is...