[Haskell-cafe] Why functional programming matters

[Maxime Henrion]

Simon Peyton-Jones wrote:
> Friends
> 
> Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important.  If you like, it's the same general goal as John Hughes's famous paper "Why functional programming matters".
> 
> Audience: some are technical managers, some are professional programmers; but my base assumption is that none already know anything much about functional programming.
> 
> Now, I can easily rant on about the glories of functional programming, but I'm a biased witness -- I've been doing this stuff too long.  So this message is ask your help, especially if you are someone who has a somewhat-recent recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc".
[...]

I think I qualify for this: I've been a long time C coder (and still
do some), doing mostly UNIX/system stuff, most notably working on
the FreeBSD kernel.  I only recently (1 year, maybe one and a half)
started learning Haskell so I still have fresh memories about my
first feelings.  One of the things that particularly impressed me
was parametric polymorphism.

As a C programmer, you tend to rewrite code to deal with linked
lists every time you need one, adding next pointers to some structure
of yours.  This kind of things get boring fast (one could also use
the BSD sys/queue.h macros, but they're ugly).

So when I discovered about parametric polymorphism, and how you can
have, for instance, a "length :: [a] -> Int" function working for
any kind of lists, I was _very_ impressed.  In a way, it is all
perfectly logical to be able to have this kind of functions, since
length doesn't need to know anything about what the list is holding,
but it doesn't make it any less impressive for a C coder.

Still on the parametric polymorphism topic, the Maybe datatype is
what impressed me next.  Everyone that has done some amount of C
in his life knows how boring it is to have functions returning
errors to the caller.  If you're lucky, your function returns a
pointer and can thus return NULL in case something went wrong.  If
your function returns an int and -1 has no meaning, you can use
that too.  But if you don't, it becomes messy quickly.  It's even
more annoying when the standard got it wrong, for instance the
dreaded atoi() function.  So, when I discovered the Maybe datatype,
I was like a kid opening presents at christmas :-).  The extreme
simplicity of the definition of the Maybe datatype is impressive
in itself, its convenience is as well, and the fact that it prevents
a whole class of bugs by making it (nearly) impossible to ignore
the fact that the function can fail is the cherry on top.

Here are my $0.02 :-).  I hope they'll be useful to you.  This is
mostly emotional and subjective stuff rather than technical, but I
believe this is also what you're looking after.

Maxime