Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2002-10-15 (10:34)
From: Eray Ozkural <erayo@c...>
Subject: Re: [Caml-list] Re: productivity improvement
On Sunday 14 July 2002 23:44, Dave Berry wrote:
> As a commercial manager, I've seen a productivity improvement of about 50%
> using Java over C++ -- mainly arising from automatic memory management, and
> a slightly cleaner language.  I would expect OCaml to have that 50%, and
> perhaps another for a more expressive type system, making 2:1.  For some
> problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> comparison, this is also the productivity improvement I'd expect to see
> using Visual Basic over C/C++ for small GUI/Database problems.

I'd expect a much higher ratio for compilers or any form of symbolic 
computation. Having went through a few C++ compilers recently I would say 
more than 1:10. The problem is that I don't have a C++ compiler written in 
ocaml in front of me, so that's just a guess ;) However, compilers for 
languages with more complex semantics (like Haskell) seems to be achievable 
in the magnitude of a few ten thousands of lines while your casual Mono 
compiler took some 10^6 lines in C if you will remember. That ratio would be 
something like 1:30, 1:40 against C, and I suspect it would still be 1:10 to 
1:20 for C++.

For a C++ compiler, the ratio would be about the same since C++ has simpler 
semantics but a more involved syntax than well designed languages. Hence more 
code for syntax, less code for semantics in the case of C++ probably making 
the compiler as complex as Haskell.

That ratio would wildly change with respect to design of the compiler of 
course. There are lots of choices even in the simplest matters. Not to 
mention the need for a good programmer. A bad programmer can eventually
manage to blow up the code size worse than a good C++ implementation ;)

Just a rough comparison,

Eray Ozkural <>
Comp. Sci. Dept., Bilkent University, Ankara
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: