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
[Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Michael Vanier <mvanier@c...>
Subject: Re: [Caml-list] Universal Serializer (was: productivity improvement)

> Date: Thu, 11 Jul 2002 02:06:15 +1000
> From: John Max Skaller <>
> >
> >BTW OCaml functional programming and memory management are two ways of
> >increasing productivity. Pattern matching on structures is also wonderful.
> >For most of the programs, I will say that the productivity rate against C is
> >around 1:3.
> >
> >Nicolas Cannasse
> >
> You must be an academic.:-) Try between 10:1 and 100:1,
> *assuming* that any libraries you need are available,
> and a reasonably complex piece of software.

I agree, but the productivity increase is going to depend a lot on the
experience and skill of the ocaml programmer.  As a newbie, I find myself
using a lot of lame imperative idioms before discovering more elegant (and
concise) functional ones.

> You just can't underestimate how difficult it is to find
> bugs in C codes of reasonable size. Such bugs almost never
> happen in Ocaml. 

Definitely, although the same could be said for java or C#, if by "such
bugs" you mean memory leaks and memory corruption.  For a more
ocaml-specific example, I find that algebraic data types with
pattern-matching (and the compiler warnings that occur if you fail to match
all patterns) is something that ocaml has that java/C# don't and which
can massively improve the quality of code (as well as making it much more

> The biggest problem in Ocaml is type inference,
> and the resulting loss of localisation of error diagnostics, but
> such compile time errors can be resolved *definitely*;
> that is, you know for sure when you've fixed them
> (because the compiler stops hassling you).

What do you mean by "loss of localisation of error diagnostics"?  Do you
mean that a type error in one location giving an expression which can still
compile (but to the wrong type) results in an obscure error message
elsewhere?  I agree that that's occasionally a minor pain, but it's hardly
in the same league with memory leaks etc.  If that's ocaml's biggest
problem, then ocaml is the best computer language I've ever seen.

> Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
> were written in Ocaml .. it might actually work!

*drool*  I would totally *love* to have this.

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: