Version française
Home     About     Download     Resources     Contact us    
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 <skaller@ozemail.com.au>
> 
> >
> >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
comprehensible).

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

Mike
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners