Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Who controls INRIA mailserv filters?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brandon J. Van Every <vanevery@i...>
Subject: RE: [Caml-list] OCaml growing pains
John Skaller wrote:
>
> I think you need to consider that the INRIA team's goals
> are closer to 'showing it is possible for a well typed
> functional language developed using theory to actually
> also compile fast code fast' rather than 'taking over
> from other industrial languages'.

It is considered.  Of course, others have other considerations.  Only a
closed source development model would keep people away from something
useful.

> Ocaml is great for writing language translators.
> The *obvious* use for it for a game developer
> is to write a game scripting language in it --
> rather than try to write games directly in Ocaml.

That's not obvious to me.  It runs afoul of the Yet Another Scripting
Language problem.  The game industry already has scripting languages
that aren't running so well on current hardware, like Lua, Python, and
Ruby.  Customizing the heck out of a language is seen, rightly, as a
waste of time.  It may be that programming tastes change as the game
industry becomes more sophisticated in its methods.  But people who can
envision, "This is how and *WHY* I should write a custom scripting
language for my game," and who can lead that to commercial advantage +
success, are not a dime a dozen right now.  Rather, we read postmortems
about how some employee blew the company's techno-wad on some half-baked
compiler he thought would be Kewl to implement.

What's obvious to me, is C++ is a low level language.  Most of the game
industry still uses it for performance reasons.  Show us something
higher level, that also has performance, and also library and tools
support, and you definitely have the possibility of a sea change from
C++.

It doesn't really matter if INRIA isn't worried about industrialization.
To a large degree, other parties can do that.  What matters, is that
INRIA doesn't try to majorly get in the way of it.

> That way you bypass all the problems, and get to
> say how great Ocaml is for writing translators with :)
>
> Oh yeah, did I mention before I've spent 5 years developing
> such a tool already .. ?

Right, but you don't have critical mass and OCaml does.  What would it
take for you to develop critical mass?  That's not a rhetorical
question, I'm wondering what you envision as your strategy.  Feel free
to e-mail me privately about it.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
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