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 BAA19801; Mon, 19 May 2003 01:21:08 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA19883 for ; Mon, 19 May 2003 01:21:06 +0200 (MET DST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h4INL5T02798 for ; Mon, 19 May 2003 01:21:05 +0200 (MET DST) Received: (qmail 35289 invoked from network); 18 May 2003 23:21:03 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay.pair.com with SMTP; 18 May 2003 23:21:03 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20030518155527.03225f30@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 18 May 2003 16:19:08 -0700 To: Lex Stein , Ed L Cashin From: Chris Hecker Subject: Re: [Caml-list] ocaml and large development projects Cc: caml-list@inria.fr In-Reply-To: References: <87wugoqjul.fsf@cs.uga.edu> <200305181113.HAA11919@nerd-xing.mit.edu> <87wugoqjul.fsf@cs.uga.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam: no; 0.00; hecker:01 checker:01 caml-list:01 hickey:01 misses:01 framerate:01 posts:01 bug:01 inlining:01 compiler:01 chris:01 ocaml:01 caml:01 recompile:01 industries:98 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >You are missing the point. It is not true that building a program requires >full recompilation. The point that Prof. Hickey made was that a program >requires full recompilation if you make a change then build *native* code. Actually, this kind of misses the point I was making (perhaps poorly). There are some programs that have a minimum performance floor below which they fail to function correctly because they have a "real time" user feedback loop. Games are one example. You can't actually do useful work on a game without being able to run it at reasonably interactive framerates because of this feedback loop. It gets worse, because you have another layer of algorithms that attempt to compensate for framerate variances, and so you're not even running the same code at low framerates, often times. So, I can't use the bytecode compiler for development and haven't been able to for most of the lifetime of my project. (See posts from over a year ago wishing I could link bytecode and native code modules together for this feedback reason.) It may be that the intersection of these two characteristics ("large scale projects" and "realtime feedback requiring native compilation") is not an interesting set for the caml team to target, although I would argue it's an important target to support if a language is to be considered "general purpose" and compete with C++. Unfortunately, this rules out a lot of games, which is my area, and one of the places where caml could have a chance at success because the project-based nature of the industry means there are clear frequent opportunities to make a big language switch (unlike industries that evolve code for decades). This is why I am evaluating caml for games by writing my current game in it. I just wish I would have known this "bug" existed before starting because it might have changed my mind. Is this documented somewhere that I overlooked? >In my experience, it isn't as bad as you make it sound like. Touching >early modules doesn't cause a recompile of everything, only modules that >directly depend on it. The inlining seems to only happen to one level. I don't think this is true, since the recompile of the parent will mean the recompile of its parents, won't it (it does in my tests)? And, even if it was true, it's still not great, because you really want to be able to edit algorithms in math3d.ml without recompiling the whole game. Chris ------------------- 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