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

Yes perhaps I've been written too much C++ in my childhood so I'm no more
able to introduce memory bugs in C++ code :))
It's easier when you're using good data structures, and a good debugger
 MSVC++ one is wonderfull , sorry of *nix guys. )

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

It is :)
Actually I really think that the reading of errors messages and the "type
debugging" that sometimes you have to do is really a part of the knowledge
of the language. I mean, instead of learning only syntax ( as in C ) you
also have to learn to handle such errors. Quite difficult in the beggining,
it becomes easier later.... ( BTW, that could be the definition of "what is
a good tool" )

Nicolas Cannasse

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