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