I'm a recovering programmer who has been designing video games since the 1980s, doing things that seem baroquely hardcore in retrospect, like writing Super Nintendo games entirely in assembly language. These days I use whatever tools are the most fun and give me the biggest advantage.
james.hague @ gmail.com
Where are the comments?
Explaining Functional Programming to Eight-Year-Olds"Map" and "fold" are two fundamentals of functional programming. One of them is trivially easy to understand and use. The other is not, but that has more to do with trying to fit it into a particular view of functional programming than with it actually being tricky.
There's not much to say about map. Given a list and a function, you create a new list by applying the same function to each element. There's even special syntax for this in some languages which removes any confusion about whether the calling sequence is
map(List, Function). Here's Erlang code to increment the values in
lists:foldlis a left fold). I would hardly call this complicated, but that step of having to pause and run through the details in my head keeps it from being mindlessly intuitive.
Compare this to the analog in array languages like APL and J. The "insert" operation inserts a function between all the elements of a list and evaluates it. Going back to the sum example, it would be "
+/" in J, or "insert addition." So this:
Now there are some edge cases to worry about, such as "What does it mean to insert a function between the elements of a list of length 1"? Or an empty list for that matter. The standard array language solution is to associate a base value with operators, like addition, so summing a list containing the single value 27 is treated as
0 + 27. I'm not going to argue that APL's insert is more general than fold, because it certainly isn't. You can do all sorts of things with the accumulator in a traditional fold (for example, computing the maximum and minimum values of a list at the same time).
But in terms of raw simplicity of understanding, insert flat-out beats fold. That begs the question: Is the difficulty many programmers have in grasping functional programming inherent in the basic concept of non-destructively operating on values, or is it in the popular abstractions that have been built-up to describe functional programming?
(If you liked this, you might like Functional Programming Archaeology.)