7 Jun
2013
7 Jun
'13
10:29 p.m.
It was thus said that the Great Ken Seefried once stated:
We've definitely found that folks whose foundation is in procedural
languages (or assembly, and I count myself solidly in that crowd) have much
more difficulty wrapping our brains around FP paradigms.
Some of the developers where I work are unfamiliar with functional
programming [1], and the description I gave of functional programming was:
No globals, and all parameters passed by value, and that's about 80%
of functional programming right there.
Those of you who understand functional programming might say that's a
gross simplification, and yes, it is. But what I just said will get you
about 80% of the benefits (in my opinion) of functional programming that is
easy to understand. I mean, who really understands monads? [2]
Other aspects of functional programming require support from the langauge
(such as closures, first class functions, lazy evaluation, tail call
optimization, monads, etc), some of which (like monads) harder to explain
than others (tail call optimization [3]).
-spc (Another aspect of functional programming---it's easier to reason
about a function)
[1] They started their careers in the 70s and for the most part, haven't
had to program in a functional langauge.
[2] Which I described as "an unspecified type which has no constant
value, even when read." Again, a gross simplification, but it's how
*I* understand monads.
[3] If the last thing a function does is return the results of another
function, as in:
return foo(params)
Then in most cases (depending on langauge semantics) the compiler
can substitute a true function call with a "goto". This is
especially useful in recursion where, if you code the function
right, internally the recursion is transformed into a loop.