The Next Mainstream Programming Language: A Game Developer’s Perspective | Hacker News Reader

The Next Mainstream Programming Language: A Game Developer’s Perspective

st.cs.uni-saarland.de

46 pointspufuwozu14 comments

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

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.

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

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

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

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.

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.

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

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

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.

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

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.

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.

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.

Reply on news.ycombinator.com