From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA17905; Sat, 20 Jul 2002 15:48:44 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA17901 for caml-list@pauillac.inria.fr; Sat, 20 Jul 2002 15:48:43 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA24851 for ; Mon, 15 Jul 2002 23:22:53 +0200 (MET DST) Received: from web13302.mail.yahoo.com (web13302.mail.yahoo.com [216.136.175.38]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g6FLMpj10826 for ; Mon, 15 Jul 2002 23:22:52 +0200 (MET DST) Message-ID: <20020715212251.19685.qmail@web13302.mail.yahoo.com> Received: from [209.55.75.200] by web13302.mail.yahoo.com via HTTP; Mon, 15 Jul 2002 14:22:51 PDT Date: Mon, 15 Jul 2002 14:22:51 -0700 (PDT) From: Pal-Kristian Engstad Subject: [Caml-list] Caml productivity. To: caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Some proponents of this mailing list seem to be convinced that Ocaml is so much more productive than C++. I find this to be a terrible mistake. From an industry where performance is crucial (games programming), I find quite a few aspects of Ocaml hard to unify with productivity. There is something to be said for syntax. Syntax should help the programmer, not the compiler. In games, it is standard to have a huge library of classes dealing with mathematical concepts. A minimum requirement is support for matrices, vectors, quaternions and splines. This usually also entails inline assembly, taking advantage of SIMD instruction sets. Operator overloading is very important to games programmers, especially for AI and behavior code. Here is a short list of items that I’ve found illogical and inconvenient for C/C++ programmers in my field: 1. The lack of operator overloading, especially floating-point operations. 2. The lack of bit-fiddling operations. 3. The lack of inline assembly constructs. 4. The non-obvious layout of variables (essential for optimized functions). 5. The non-obvious differences between arrays and “inline” arrays. 6. The non-obvious behavior of garbage collection. One has to understand that when performance is super-important, one cannot just rely on the compiler anymore. Some sections of the code have to be optimized by hand, and it is here that Ocaml falls short of C/C++. As an example, imagine that you want to define: struct Elems { u32 handle; u16 numData; u16 index; }; struct Data { Elems elem[128]; u8 buffer[16 * 1024]; }; Data *data = (Data *)0xabadbeef; This is a very clear layout. One wants the data in a very specific memory configuration. One needs to know the exact sizes of the data structure. This could for instance map to special hardware that is laid out in this way. This is impossible to do with Ocaml. Now, Ocaml is a great language for some tasks. I’ve successfully used it with Facile, a constraints solver. The parsing of the input was a breeze compared to a similar C/C++ solution. But one can’t go around claiming that Ocaml is a productivity enhancer for all tasks. Games programming certainly isn’t one of them. PKE. __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.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