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: 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
>elsewhere?  
>
Yes.

>I agree that that's occasionally a minor pain, but it's hardly
>in the same league with memory leaks etc.  
>
Agree.

>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, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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