Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jean-Marc Eber <jeanmarc.eber@l...>
Subject: Re: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)
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
"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
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
chain, the intermediary steps "adapting" automatically thanks to the type
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
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

Bug reports:  FAQ:
To unsubscribe, mail  Archives: