> Nicolas Cannasse seems to believe that "productivity"
> and "performance" are orthogonal concepts. They are
> not always. For some tasks the performance of the
> algorithm determins if the program can be put into the
> application. Hence, if the program executes too
> slowly, the program is useless and the time spent on
> it was a waste. In other words, there was no
> productivity at all.

Sorry but i don't call that "performance" but "complexity".
Theses terms are quite differents. Using algorithm with a lower complexity
leads to a massive gain of performances, while increasing performances by
performing "by-hand" optimizations can result in loss of portability,
clarity and so make the code maintenance almost impossible, resulting a loss
of productivity.

> I commend Nicolas for trying to use O'Caml in a games
> setting.

That's quite funny because i'm actually doing it :)
We ( my company ) are actually building a real-time 3D game almost entirely
written in OCaml.
Currently the game is running in bytecode, without any performance
consideration (except algorithm complexity) and even on a low-CPU testing
PC, all is working very well ( great FPS, multithreading , etc... )

> We, however, can not afford this - instead
> the company designed and implemented a specific
> language in order to be able to optimize _and_ be
> productive. This language has high-level constructs as
> well as low-level constructs --- and they can be
> freely mixed.

Once again, OCaml can be easily mixed with C to enable at the same time high
performances for time-critical operations and high productivity for top
level operations ( means : control the low-level game engine ). All the
current games are using such a top-level called "script" : most of the time
this langage is developped by the company itself for its own use, resulting
a large amount of work and at the end you'll have a more-or-less well
designed langage with more-or-less bugs and more-or-less performances.
That's why Ocaml is good choice :)

Nicolas Cannasse

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