

The Next Mainstream Programming Language: A Game Developer’s Perspective - pufuwozu
http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

======
tel
_Purely Functional is the right default

Imperative constructs are vital features that must be exposed through explicit
effects-typing constructs_

This is precisely the argument Haskellers make every time someone complains
about algorithms that are difficult to formulate functionally.

------
azharcs
For those of you, who don't know, Who Tim Sweeney is?

Tim Sweeney is the founder of Epic Games and the person behind very famous
Unreal game engines. John Carmack,Tim Sweeney have been some of my heroes from
gaming world.

[http://en.wikipedia.org/wiki/Tim_Sweeney_%28game_developer%2...](http://en.wikipedia.org/wiki/Tim_Sweeney_%28game_developer%29)

------
jefffoster
There's some further discussion of this over at LtU (<http://lambda-the-
ultimate.org/node/1277>)

------
tomstuart
More relevant now than ever, but note that these slides are ~4 years old.

------
sundarurfriend
Those requests for the ability to have range limited data types reminds me
strongly of Ada.

~~~
jcl
Me too. And as Tim might hope, Ada seems to be more popular among safety-
critical software implementers. However, Ada also seems to run a bit slower in
practice than C -- which is odd, considering that you are handing the compiler
more information about the code.

------
wglb
This might be old, but it very excellently done. One thing I like about it is
that the assertions an conclusions are backed up by 1) real-world experience
2) deep understanding of programming language issues.

------
waterlesscloud
Slideshow from Gears Of War developer, seems to be advocating Haskell as the
"next mainstream programming language".

~~~
SirWart
He actually mentions at the end of the slides why Haskell doesn't work. I
would phrase it as "Let's take these really good ideas from Haskell and move
them into a more mainstream language."

~~~
etherealG
surely if mainstream is the thing you want, then more people using haskell
would solve that? I don't see how moving to another language helps the
mainstream problem, actually it hinders it since less people will be using
your new language than are using haskell already.

~~~
teamonkey
"Mainstream" isn't the only reason given for not using Haskell. He also says
that lazy evaluation is a bad default (too costly) for games and the syntax is
too complicated.

~~~
nightski
The syntax too complicated bit bugs me. Haskell syntax is very minimal, more
lisp like than C like. The syntax is "different" than traditional imperative
languages but coming from Lisp/Scheme/F# background it was very easy to pick
up.

I am not sure I buy that lazy evaluation is too costly either, as it is
actually what buys performance gains in some areas. That was a broad statement
and it doesn't hold everywhere but I just want to say that it isn't cut & dry
like you make it sound.

I would say the only argument he makes against Haskell that I totally agree
with is its inference engine. I have very mixed feelings about type inference.
It is very nice because it makes everything so concise, yet I often find
myself writing function types just for clarity. Also type errors are not fun
to track down as he shows in the slide.

~~~
jerf
As much as I like Haskell, I would be nervous about using it in a AAA-class
game engine. The space leaks that lazy evaluation can produce could end up
even harder to debug than usual in such a complicated product.

Please note I said "nervous", not "I would never consider it ever". Another
couple of years of development and I might be less nervous; Haskell has been
making a lot of progress lately. Some stuff in the absolute inner core might
still be C or Assembler, but I could see the bulk switching to some other
language.

~~~
saucetenuto
Space leaks are the real problem, and not just for the reason you state.

These days it's hard to even buy a computer with less than a gig of RAM, but
the Playstation 3 - the most powerful console of the new generation - has only
256 megs. Granted, they're 256 _really fast_ megs, but it's still a tiny
amount of space by modern standards. You don't even have a hard drive to swap
to when you run out of space - if a memory allocation fails, you work around
it by hand or you crash.

If you're going to write a game engine that's meant to run on consoles, you
really need fine-grained control of _all_ the memory allocation in your
system. That'd be my big worry with Haskell, more than speed or garbage
collection latency or whatever.

