

Functional programming explained properly - dhaivatpandya
http://poincare101.blogspot.com/2012/02/functional-programming-explained.html

======
gatlin
I would add the following.

Just think of the word function for a moment, in an algebraic context. A
function is a a relation (ie, a mapping from a set of things to another set of
things) where each element of the domain maps to at most one element of the
range. Now, the inverse does not hold: any given output might have several
inputs that lead to it.

For example, f(x) = x^2 is a function because f(2) is always 4, no matter what
end of story. f(-2) is also always 4, and that's okay.

In most languages where you use "functions" you can modify state as part of
the function doing its thing. Modifying external state opens up the
possibility that, if we are writing a function `func`, `func(A)` might
somethings return B or sometimes return C. That violates the definition of a
function.

This could happen if our `func` example mutates a variable that it relies on,
alters a database, etc. If that variable, or that database, is used elsewhere
in the program, you open the door for non-determinism. In other words,
bringing in external state could very well mean that your function isn't a
function at all, in a mathematical sense.

Sticking with mathematical functions means that your program is more
deterministic. It means you can reason about the correctness of your program
more easily. It means that you can write a series of reusable components which
can be composed any which way without too much trouble, and thus refactoring
and creating libraries is much easier.

Only at the "edge" of your program, where it absolutely must mutate the
outside world in some way, should you violate this.

~~~
dhaivatpandya
I really like this, I'll incorporate in once I get a bit of time.

------
ceol
Minor nitpick: decoupling isn't the ability to test things separately—
although it _allows_ you to do that. Decoupling is the minimization of a piece
of software's dependence on another.

~~~
dhaivatpandya
Thanks for the feedback!

That was a slight "oops", sorry :)

~~~
ceol
No problem! Your post was pretty interesting. As someone who's never used
Haskell ( _ducks_ ) it's nice to hear about its functional advantages.

If you're doing another post, it would be nice to see examples of a functional
implementation of addNumbers.

~~~
dhaivatpandya
Sure, I'll do a post like that :) Seems like a good idea, thanks for giving it
to me.

------
lutusp
> You're probably saying "WHAT?!! How am I supposed to implement a counter
> then?!", and that's solved entirely by the fact that you can use recursion.

Yes, true, but IMHO the author ought to have explained that in most cases the
compiler turns this apparent recursion into more efficient code that doesn't
recurse unless it must, so you get the best of both worlds -- a pure function
in source, and efficient code for the machine.

~~~
dhaivatpandya
I refrained from saying this, because this isn't always true, and as graph
reduction processors slowly get introduced, this is going away.

