> On Thursday 05 March 2009 02:15:20 Pal-Kristian Engstad wrote:
> > Jon Harrop wrote:
> > > On Wednesday 04 March 2009 23:18:21 Pal-Kristian Engstad wrote:
> > >> Sure -- those are probably not jobs that require performance, nor have
> > >> resource constraints.
> > >
> > > I do not believe that C++ is significantly faster or better at handling
> > > resources than higher-level languages.
> >
> > Have you ever tried to conform to a specific memory layout? We are often
> > talking directly to hardware, and in those cases it is a prerequisite to
> > be able to produce data that is in the exact format prescribed. Often
> > these things are, put an 17-bit ID followed by a 3-bit CODE followed by
> > a 12-bit LENGTH field, after which follows LENGTH items each of size
> > that is some-function-of CODE.
> >
> > This is usually not a problem when a small part of your data needs to be
> > described this way, but when a large portion of your data needs this
> > formatting, you can see that OCaml or Haskell records simply doesn't
> > work very well.
> 
> I agree with the symptoms but not with C++ as the treatment. Granted you 
> cannot write such code directly in OCaml or Haskell but you can generate the 
> code using tools like LLVM 

Come on, can you stop all those stuff about LLVM. The guy works in a game company
with people knowing C/C++ for decades, with quite a lot of legacy code I guess, and you
arrive with your "hey you should use LLVM" that almost nobody knows about. 

Oh, and by the way, in which programming language is written LLVM ? :) 

Valgrind is written in C (and julien seward, its author knows very well 
Haskell), Qemu is written in C, because I guess indeed C struct and union
and bitfields makes it easy to match directly to the hardware (no marshalling,
there is direct mapping).


> It doesn't need to be a JIT and, actually, HLVM already supports both JIT and 
> standalone compilation.

So what you propose to his company is to switch from C++ to HLVM ? :) 
Be serious.