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 KAA31208; Wed, 24 Jul 2002 10:02:55 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 KAA31226 for ; Wed, 24 Jul 2002 10:02:54 +0200 (MET DST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6O82sH00310 for ; Wed, 24 Jul 2002 10:02:54 +0200 (MET DST) Received: from mel-rta9.wanadoo.fr (193.252.19.69) by mel-rto4.wanadoo.fr (6.5.007) id 3D18589F00F3485A; Wed, 24 Jul 2002 10:02:52 +0200 Received: from warp (217.128.142.232) by mel-rta9.wanadoo.fr (6.5.007) id 3D2A791A00761316; Wed, 24 Jul 2002 10:02:52 +0200 Message-ID: <002201c232e8$707284f0$0700a8c0@warp> From: "Nicolas Cannasse" To: "Pal-Kristian Engstad" , "OCaml" References: <20020722174635.18927.qmail@web13307.mail.yahoo.com> Subject: Re: [Caml-list] Caml productivity. Date: Wed, 24 Jul 2002 10:02:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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