Re: [Caml-list] Caml productivity.

[Tom <tom7ca@yahoo.com>]

> Some proponents of this mailing list seem to be
> convinced that Ocaml is so much more productive than
> C++.

It is.  For many problems.  Yours may not be one of them.

> I find this to be a terrible mistake. 

The terrible mistake is thinking that there is one programming
language that works really well for everything.  There isn't.
There never will be because it's a logical impossibility.

> From an
> industry where performance is crucial (games
> programming), I find quite a few aspects of Ocaml hard
> to unify with productivity.

That's a silly generalization.  There are many excellent
games that do not require high performance computing in
any form.

However, even those games that do require high-performance
computing (say, for 3D graphics or AI) can generally be
partitioned into a small computational kernel and a large
set of high-level constructs.  And you don't even have
to reinvent the wheel--many such kernels alreay exist
and are easy to hook up to OCAML: BLAS, LAPACK, OpenGL,
various game and object graph libraries (CrystalSpace, etc.),
neural networks, and many others.

Many high-performance games are programmed in an interpreter 
coupled to a bunch of those libraries.  OCAML gives you a leg up
because of better compile-time type checking, a good foreign
function interface, and the ability to do modestly high
performance computing in OCAML itself in a pinch.

Two specific points:

> 6. The non-obvious behavior of garbage collection.

Anything you don't understand is "non-obvious".  However,
GC is no more "non-obvious" than manual storage allocators:
you have to learn how to write high performance code in
either of them.  GC'ed languages are different: what
you are used to in C/C++ will not work well.  (That is
not to say that the OCAML collector couldn't be improved
for soft real time problems.)

> As an example, imagine that you want to define:
> [packed data structure layout example follows]

Yes, control over layout is nice for high performance
computing.  It could be added to OCAML.  Are you volunteering?

Note, incidentally, that neither C nor C++ make a lot of 
actual guarantees about layout of data in memory; code
that actually depends on it is, in most cases, unportable.
Some compilers will even change layout under different
optimization options, so beware.

C and C++ are great languages.  I write a lot of C++
code.  But C and C++ should really be considered niche languages,
for specific, low-level system tasks, computational kernels,
or certain high-performance numerical uses.  Most code people 
write in C or C++ (GUI software, many games, etc.) would be much 
better, and more productively, written in something else.

Tom


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
-------------------
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