Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Caml productivity.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-27 (04:42)
From: Issac Trotts <issac@m...>
Subject: Re: [Caml-list] Caml productivity.
On Fri, Jul 26, 2002 at 02:42:27PM -0700, Chris Hecker wrote:
> It's going to be another generation or two before a higher level language 
> like caml is going to be appropriate for console games, and I don't think 
> there's any way around that.  I think it's just starting to be okay for PC 
> games, but even the next gen consoles are going to be too memory 
> constrained and it's always much more cost-effective to super-optimize a 
> console game (both memory- and cpu-wise), at least for the next few ship 
> cycles.

There's already strong evidence that it's possible to use a higher 
level language to produce a successful console game: Naughty Dog's Scheme dialect 
(GOAL) on Jak & Daxter for the PS2.  They claim to have used it for most 
of the game.  One thing that isn't clear is how they avoided running 
out of memory from fragmentation.  Maybe Pal-Kristian Engstad can shed 
some light on this.

> On the original topic of this thread, I am still withholding judgment on 
> caml for game programming until I actually finish my game, but I sincerely 
> doubt it will be anywhere near 3x as productive for the kind of imperative 
> simulation-y code that makes up a game.  If any game company could actually 
> get 3x productivity out of their programmers, they'd retrain everybody in 
> an instant.  

The figure of 3x is relative to a particular set of circumstances.  If you're
writing something from scratch that is well matched to OCaml's feature set 
then it's easy to believe that you could write it three times as fast as you
could in some other language, given equal proficiency.  In contrast, a
game company would take a big productivity hit in the short run (as well as 
maybe losing some programmers) if they forced everyone to switch, because 
most likely they already have a large code base written in other languages 
that would need to be converted or interfaced with, as 
well as programmers who are much more effective in these languages than 
they would be as novice OCaml programmers.  Retraining in OCaml wouldn't happen 
in an instant because of OCaml's steep learning curve and relative lack of 
documentation.  (I have yet to find a bookstore in my area that carries 
anything about OCaml.)  Hiring would also be quite a bit more difficult
since so few people are proficient in OCaml compared to other languages
used in games.

> 3x is huge.  I think caml is definitely more fun to program 
> with, but if it's at all more productive, it's going to be in the 10-40% 
> range at best (and most of that is going to come from the gc).

This makes me wonder: have you tried out the Boehm-Demers-Weiser conservative 
garbage collector for C and C++?  

You mentioned that OCaml is more fun to program in.  I agree.  This is important
for its own sake and because happy programmers will tend to produce better work 
and stay around longer.  

Issac Trotts        

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: