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