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: 2002-07-12 (12:41)
From: John Max Skaller <skaller@o...>
Subject: Re: [Caml-list] Universal Serializer (was: productivity improvement)
Michael Vanier wrote:

>>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.
Ocaml does imperative programming better than C and C++ too.
So even your 'lame' imperative code can be produced faster and more
reliably in Ocaml.

Example: values (declared in let bindings) scope better.
Variables (references) must be initialised -- sometimes this
is a pain, but usually it is a bonus.

>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. 
 Well, if you run java or C#, you still have to cast 'object' down, and 
so you can get run-time
errors -- where using Ocaml this class of error cannot happen.

Ocaml run time errors include array (and string) bounds exceptions and 
infinite recursions:
static type checking could detect the first, but not the second.

>>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

>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,
It's one of them (IMHO)

>then ocaml is the best computer language I've ever seen.
I agree :-)

>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.
heh :-)

John Max Skaller,
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.

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