There is another argument in favour of FP (more precisely in favour
of polymorphism + type synthesis) that is, I think, often not enough
emphasised even if, unfortunately, it also only works "in the large".

It's the easiness with which
you can *modify* a big piece of code. More precisely, I'm speaking here
about code that is maintained over many years (say 10 or 15 years) and
constantly
"updated" to work under new circumstances.  Most of the time, this means in
fact a
"generalisation" of the software. A typical example is for instance a
"program" that manipulates, say, floats and is generalised for manipulating
sets of
floats (typically represented as lists). The old case being just the
particular
case of a singleton list.

When you are doing this kind of "software upgrade" with, say, OCaml, it
appears often that you just have to change and adapt the two ends of your
treatment
chain, the intermediary steps "adapting" automatically thanks to the type
unifier.
It's the possibility to do minimal explicit type annotation of your source
code (with
type security albeit of course) that gives incredible flexibility.

Even after a few years of FP programming, I'm still fascinated by the
easiness of patching for instance the OCaml compiler itself (not a small
piece of
code indeed!) by chirurgical minimal source code modifications (replace a
simple value by a tuple etc…).

I miss a FP textbook (but perhaps I'm wrong and someone on this list knows
one) that not only explains that it is easy, sure etc… to write programs in
FP,
but that shows how easy one can *transform* a FP program, by keeping the
"illusion" (thanks to the type unifier) of doing only a minimal change.


Jean-Marc Eber
LexiFi Technologies
17, square Edouard VII
F-75009 Paris - France
tél : 33 1 53 43 92 48
fax: 33 1 53 43 94 94
email: jeanmarc.eber@lexifi.com


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr