Browse thread
[Caml-list] productivity improvement
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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