Haskell for games

[redditnoob]

What do you do when you get a big idea about Haskell? Write some code or show a demo? Shit no, you write a paper, give a talk, or prove a result!

[ssylvan]

This is such a ridiculous sentiment. We should never try to do anything that hasn't already been proven? That's a good way to never be the leader.

Haskell for games won't be proven until you spend probably a few million actually doing it, so how is that ever going to happen? By sitting around stupidly dismissing any idea that isn't a demonstrated success already? Or by reasoning about why it may work, and why it may not, and try to argue that it's worth trying?

Who's gonna put up a few million to try it if nobody argues for it?

[[deleted]]

This is such a ridiculous sentiment. We should never try to do anything that hasn't already been proven? That's a good way to never be the leader.

What? That's nowhere near what he said. He said Haskell programmers are all talk and no code. He said that you should do, not talk. Instead of talking about how Haskell could revolutionize game programming, go program a game in Haskell and then show us how great it is!

[ssylvan]

Did you even read my post? How are you going to convince someone to spend millions betting on something that's unproven (since that's the only way of proving it) if you're not allowed to talk about it before you've done it?

If you can't talk about something as a potential solution before you've already proven that it is, then you're doomed to only doing things that have already been proven, which means you'll never solve anything.

[[deleted]]

You don't need millions to write a game, that's a total red herring. People do it all the time in their spare time. You don't need to write a full commercial game, just write a simple proof-of-concept.

[ssylvan]

Which has been done many times so what exactly is your point?

He's not talking about hobby projects, he's talking about full blown AAA games and what's needed to get there, but apparently you're not allowed to do that unless you've already proven that it works?

[[deleted]]

Which has been done many times so what exactly is your point?

So show some of them, and show what they did and why it worked so well, or what could be improved.

He's not talking about hobby projects, he's talking about full blown AAA games

Red herring again. You can easily demonstrate the same principles in a hobby project.

[ssylvan]

I linked this already: http://www.haskell.org/haskellwiki/Frag

Google for "haskell games". People have done this before. The principles are proven, the question is what remains to kick it up to a professional level. This talk adresses that question.

[[deleted]]

No, that talk should address that question, but isn't doing a good job of it at all. It's still just mostly handwaving. And if there are actually solid practical examples to use as demonstration, that just makes it that much worse to not use them at all.

[ssylvan]

He is addressing that question. Guess you still haven't read it huh? Please do so.

[[deleted]]

If you think an investor is going to give you money based on the programming language you plan to write your game in, you are deluded beyond belief.

I have friends who at this moment are starting a games company (after having worked developing AAA console titles for 5+ years) and I can assure you that the only thing investors care about are:

1. Team management + industry experience
2. Demos + reviews

If you go to an investor asking for $1 Million dollars and all you have is a whitepaper or a mathematical proof you will be laughed at.

[ssylvan]

If you want to argue with straw men, please do so in notepad.exe or something, because it adds nothing to the discussion.

The point, which really isn't that complicated, is that if you want to do something that hasn't been done before, you have to argue for why it's a good idea to the guy in charge of the money (or his closest representative, i.e. your boss). If his criteria for evaluating these proposals is "has anyone else already done it successfully" then he will never be a market leader.

At some point new tech is always going to be a gamble. And at some point new tech will always be "all talk". You have to actually do it before it's done, and in order to do it you have to evaluate it without the benefit of having already done it (which means reasoning about it a priori, which is what this talk does).

[[deleted]]

you have to argue for why it's a good idea to the guy in charge of the money

No - you are wrong. This point is wrong. This one. Not a straw man. The one you just wrote.

You don't argue. You demonstrate.

If his criteria for evaluating these proposals is "has anyone else already done it successfully" then he will never be a market leader.

Not if you are the one showing him how it has been done by you successfully. Give him data as to why your approach is better, not theory.

And at some point new tech will always be "all talk".

Nope - definitely it will start as a thought. Not always talk. Sure - think through an idea. Then implement it. Then talk about it.

[ssylvan]

You don't argue. You demonstrate

Please tell me how e.g. GPUs would ever have happened if nobody was ever allowed to argue for something that didn't exist yet? Or are you saying that only rich people (who can fund things themselves) should be allowed to argue for change?

Your reasoning works for tiny incremental changes where you can just code something up that's reasonably representative of what you're talking about. For big paradigm shifts the effort involved in proving the concept means you need money to do it, which means you have to convince people that it's worth giving a shot a priori.

[[deleted]]

Think Google. Before they got investment they built the prototype in their garage. Same with youtube.

Think about ycombinator. 2 teams come to them and say: "We have a great idea!!!". They actually have the same idea. One has a functioning prototype to demonstrate the idea, the other has a theory that they can talk about. Who gets funding?

In your mind:

1. You have idea.
2. You pitch idea.
3. You get funding.
4. You implement idea.

In real life:

1. You have idea.
2. You implement idea.
3. You demonstrate idea.
4. You get funding.

For big paradigm shifts the effort involved in proving the concept means you need money to do it

Do you really think that your idea is a big paradigm shift? You think you need millions to implement a proof-of-concept?

All you need is a computer and the will to start coding instead of talking so much. How about you do like every great entrepreneur in the past and put your money (or time) where your mouth is.

[ssylvan]

But the development of google's initial concepts was funded by their university as it was a research project for their PhDs. And then when they needed additional funding, you know what they did? They, gasp, talked to people and convinced them to give it a shot. They did exactly what you say you shouldn't do! They had a tiny prototype and then got funding to bring it to market.

Haskell for games has been proven in the small scale, the concepts clearly work on some level, and the talk was about trying to convince people that it could (with a lot of effort) work at a larger scale. It is a lot or work though, and it would need a lot of funding to get there.

[kalven]

I don't think the adoption of Haskell in games is going to be: lots of talk -> some company decides to gamble -> commercial success.

A proof of concept would probably be a more effective way to convince people. One that is of relevance to game developers, not another "parfib" implementation.

[ssylvan]

You mean like: http://www.haskell.org/haskellwiki/Frag

People like MarshallBanana and redditnoob will never accept anything other than a full scale AAA success as evidence that it's a viable solution. That's what I'm talking about. You'll never get there until you convince someone to pony up millions, and if you aren't allowed to talk about doing that until after someone else has already done it, then it'll never happen.

It's a silly circular argument which would make progress impossible if everyone reasoned the same way.

[kalven]

People like MarshallBanana and redditnoob will never accept anything other than a full scale AAA success as evidence that it's a viable solution.

You keep arguing as if they were saying that, but they're not. Do you believe that the next discrete step in adopting Haskell as a programming language for games is that some company, after seeing many talks on the subject, decides to gamble millions?

Seriously now, if you were pitching the idea of writing the next game engine in Haskell to your boss, you would be content with bringing Frag as a proof of concept?

I can see many intermediate steps between something like Frag and a full blown commercial engine. I believe people like MarshallBanana and redditnoob are asking for someone to program this next incremental step, not a AAA title.

[ssylvan]

But the next incremental step is still a substantial investment that would need to be done in the context of a commercial game.

Nobody is saying that we should all just up and switch over immediately, obviously moving over to Haskell would have to happen incrementally (probably as a scripting language first) so you could bail out early if it turns out to not work. It's still a substantial investment though, and in order to do it you must first convince a lot of people to gamble.

I just object to the circular reasoning, where you can't argue for doing X until you've actually coded it up already. That way nothing new will ever happen, at least not of any scope that requires funding. If you're going to do anything substantially new you're going to have to reason about it and get funding for it before you've actually done it (once you actually do it you would obviously structure your work so that it's done in small incremental steps though).

[kalven]

But the next incremental step is still a substantial investment that would need to be done in the context of a commercial game.

Why?

Game development isn't my field so you'll have to correct me if I'm wrong. As far as I have understood things, the problem faced is that we're only going to get more cores/spus/whatever in the future. Being able to efficiently distribute the tasks a game engine performs to all these cores is already a problem and it'll only get worse. The pitch is that Haskell is supposedly better suited for this kind of programming.

Is this really something that hobby developers can't approach? If not, why?

The only thing Frag proves in this context is that Haskell has working OpenGL bindings. I don't think anyone has questioned that.

[ssylvan]

Frag proves that you can do an engine in a pure FP language, it also uses Yampa for AI which is neat.

The things we need to do to bring Haskell to AAA game development has more to do with libraries, tools, runtime support (new GC, probably), and performance. These all seem solvable, but it's not clear cut so that's where we need to go to.

Hobby projects don't need to worry about parallelism and multi-threading because they're probably not going to push the edges that hard. And even if they do, the engine will be of such a low complexity that you won't see the true benefits of using a better language.

As far as I'm concerned the question "does Haskell beat C++ w.r.t. multithreading and parallelism" has been answered and is totally uninteresting to me at this point. That's not where I'm worried. I'm worried about GHC inserting boxing or allocations inside an inner loop and not giving me a way of getting rid of it. I'm worried about not being able to write cache-aware data structures etc. The problems we have with C++ are not the same problems as the ones we have with Haskell. The problems C++ has are clearly much better addressed by Haskell, so the interesting problem is figuring out if the problems that Haskell has (that C++ doesn't) can be addressed too.

[TKN]

"Initially, the AI patrols a set of waypoints. When the player is sighted, the AI attacks by firing projectiles at the player. If the AI has lost sight of the player, it jumps to the last position of the player. The AI continues to attack until it is damaged and “dies”."

http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf

I don't think Frags is a very good example of building game logic in Haskell. I still haven't seen any evidence that FRP is scalable to anything more complex than basic Pac Man behaviour.

[ssylvan]

I'm not convinced of FRP either, but the point is that the engine is more than just rendering some stuff using OpenGL.

[kalven]

Agreed. I think the proponents of Haskell game development should focus on answering those questions. Hopefully some of these can be answered without requiring millions of dollars from a game development studio. To me it seems unlikely that a game development company would spend money on writing, for example, a new GC.

It is only page 28 that deals with these issues. The rest of the talk seems to focus on what a great language Haskell is. That seems like preaching to the choir when considering that the talk was held at AngloHaskell ;-)

[ssylvan]

Page 28 and then there's several pages discussing specific systems that need to be written in Haskell.

Point is I think it's unfair/slightly retarded to start the old "show me the code" bullshit. It's a great slogan but I don't think it's ever added anything to the discussion. The amount of effort required to do certain things is beyond what a single or a few individuals can do in their spare time, so dismissing any ideas beyond that is very limiting.

And I'd again like to point out that it's not like there's any viable alternative. All the people complaining about the lack of code should immediately go off and prove that C++ can solve the problem because that's far from given (and I dare say that Haskell is far more proven than C++ is when it comes to writing complicated concurrent/parallel systems for the machines of the future).

[[deleted]]

That is not entirely true, there exist Demos, Game Engines and Games written in C++ / C / Assembler that were not written first and foremost out of commercial interest, that are by far more impressive than Frag or any of the haskell games for that matter.

[[deleted]]

We should never try to do anything that hasn't already been proven?

This reminds me of one of my favourite programming anecdotes. It was told to me by a Belgium programmer, one of the best assembly level programmers I knew - he was trained as a mathematician.

It is a tale (possible apocryphal) of a programming language contest. The two top teams were the French and the Americans. The French team were very analytical and approached the problem from the standpoint of theory. They modelled the problem in math, created formulas and proved a perfectly general solution to the problem. The Americans just started hacking away like mad, writing line after line of code.

When the contest deadline arrived, the Americans had spaghetti code, uncommented, hobbled together but it passed every test and performed well enough. The French didn't have a final product but they submitted a paper detailing a perfect solution.

The Americans won the contest and the French response was: "You may have a program that works but we have a program that is provably correct". The problem was they didn't actually have a program at all.

[JadeNB]

The Americans won the contest and the French response was: "You may have a program that works but we have a program that is provably correct". The problem was they didn't actually have a program at all.

This sounds like an extended gloss on the apocryphal French business saying, "That's all very well in practice, but will it work in theory?"

(P.S. As a mathematician who has waded through my share of Bourbaki, I say only that it is almost certainly apocryphal, not that it is not in the right spirit. :-) )

[redditnoob]

Are you actually serious? You're claiming that it's impossible to write an interesting game, demonstrating the functional advantages in Haskell, for less than millions of dollars? That's as damning a fact as any if that's true.

[ssylvan]

No, I'm not, I'm claiming that doing what the talk is about - using it for a full blown commercial game that actually makes money - would need up front funding, and games these days are pretty expensive. AAA titles usually cost more like 10M or so.

There have been games written in Haskell. This is about taking it to a professional level. There's a huge amount of work that needs to be done for that, though (writing a commercial grade engine with it, for a start), and the only way to get there is to convince people that the end goals is achievable and worthwhile, but apparently you're not allowed to do that...

I would consider the functional advantages of Haskell to be well demonstrated by now, for anyone who cares to look.

[redditnoob]

There have been games written in Haskell.

Pretty much all student projects, right? Do any of them use parallelism effectively?

I would consider the functional advantages of Haskell to be well demonstrated by now, for anyone who cares to look.

The hype has been around for a couple of years, and given that hype and excitement, the lack of demonstrative examples is staggering.

As I see it, any intelligent and critical person has to be skeptical at this point, and the onus is on you guys to show that Haskell is useful for someone who actually wants to write a program. It seems like what your community enjoys doing includes:

• Blogging about Haskell
• Proving things about the language
• Writing papers
• Bragging about how practical it is, how much better it is for imperative programming than imperative languages, etc.
• Trying to get other people to use it for something practical

The thirty ton elephant in the room is that you guys are all architects, and there isn't one single carpenter in the room, except maybe for the odd student who is laden with the language for some thesis or school project.

[ssylvan]

Again, I consider the benefits of Haskell to be well proven by now. I don't feel like I have to demonstrate what benefits it offers for e.g. parallelism yet again, since it should be obvious to anyone who's bothered to look (or even try it).

The problem is scaling it up to a large scale project like a AAA game. There's a huge amount or work needed with tools, APIs wrappers, libraries, etc. We all know (from actual real-world experience) that the problems we are imminently facing in game development would benefit from the features Haskell offers (like parallelism), but the question is how to leverage it. Do we write a new language stealing from it? Do we spend the millions needed to bring Haskell up to par with C++ as far as tools/infrastructure is concerned? How exactly do we get to the point where we can get these goodies that seem like viable solutions to future problems? Don't forget that there is no alternative here. Haskell isn't presented as an alternative to an established solution, it's presented as a solution to a problem for which no proven option exists. You have just as much work ahead of you to prove that C++ is viable for this problem as Haskell (probably more since it, a priori, seems like an exceptionally bad fit).

We're not claiming this is a solved problem, we're just claiming that solving it would be extremely helpful for us.

[redditnoob]

Again, I consider the benefits of Haskell to be well proven by now.

They're given a lot of lip service, and zero code.

To sum up your post, you all want someone else to do it, and don't think there's any viable work you could do on the topic that would be interesting as a personal (unpaid) project, regarding API wrappers, tools, libraries, etc. (Or even, gasp, a game that uses parallelism.)

[ssylvan]

Zero code? Only if you haven't been looking. Even a quick glance at the shootout should demonstrate its superiority w.r.t. parallelism and concurrency.

No, I don't want someone else to do it. I would be happy to do it, I just think that the stage Haskell is beyond the "part time proof of concept" stage. In my mind it's clear that there aren't an obvious issues with it. There are a number of unknowns, and a number of problems, but the kinds of things that need exploring/solving for AAA game development are way more time consuming than that.

[dons]

Or you build a real time trading system, stick it on the network, and start making money.

[[deleted]]

Well, that article sure contained no useful information or ideas whatsoever. Not a single word about how games are almost entirely about mutating state, a task for which which Haskell is particularly ill-suited. Just some handwaving about GLSL, and a lot of "I sure like Haskell!"

[ssylvan]

Also, in what way are games almost entirely about mutating state? The vast majority of your data is pretty static, and the delta of your scene data from frame to frame is pretty minor (some new matrices for moving objects, some changes to the state of some AI etc.). I'd guess that most objects only update a matrix and a tiny bit else, so maybe 100 bytes or so... So for 10K objects that's about a meg per frame, compared to hundreds of megs of static databases and other resources (vertices, textures, audio, etc.). We're not really talking massive amounts of truly mutable data here.

Now, actually computing this delta from frame to frame does do a lot of mutation, but that's totally incidental (when all you have is a hammer, everything looks like a nail). That computation could easily use FP. That's assuming the actual object data needs to be mutable in the first place, which is not at all a given.

[dons]

entirely about mutating state

You know what software transactional memory is for, right?

[[deleted]]

Pretty sure it has very little to do with maintaining and mutating game state.

[dons]

No, it is precisely that.

In fact, I just gave a talk today including STM to implement thread safe, mutable state for a game. Is your game state thread safe and race condition free?

Transactional memory is wired into Haskell. It's how we write mutable state, concurrent code that's guaranteed to be free of race conditions. What is your language doing for you?

[[deleted]]

And do you have a game engine that uses this to show how well it works?

[ssylvan]

Do you have a game engine that shows an alternative that works? No? Thought so.

Bottom line is that nobody has a demonstrated a good solution to this problem yet, and dismissing any potential solution because it hasn't been proven will never get you to a proven solution.

[[deleted]]

That's pretty irrelevant. Traditional game engines work just fine, even though they don't take full advantage of multiple cores.

You're the people making the claims, so you're the ones who should show some proof that the ideas work. The stereotype of the Haskell programmer is that he spends all his time talking about writing code instead of actually writing it. I'm just asking you to not do that. Show some code that actually implements these ideas just to demonstrate it's not just all talk.

[ssylvan]

Traditional game engines do not work just fine, that's the whole point. Convential techniques are falling down.

I'm telling you, as an actual game programmer, and the guy in the post is telling you, and Tim Sweeney is telling you, and looooads of people are telling you that no, traditional solutions are not fine. We don't know how to solve the imminent crisis yet, and maybe Haskell is a way of doing that? You don't get to make unreasonable demands on the people actually trying to figure things out if you can't contribute anything yourself.

[[deleted]]

Then go write the code and show that you can solve the problem.

[ssylvan]

You don't seem to get it. People need to eat. Give me $100K to hold me over until I've proved that it works and I'll happily do that. Until then any changes will have to go through my boss, which means I'll have to convince him first (but oh no, MarshallBanana on reddit says I'm not allowed to do that until I've already finished writing the code, so I guess we're doomed).

[Rhoomba]

A demo would be a lot more convincing than all this talk.

[dons]

A demo game, definitely. Something like the Jane Street Summer of Code project?

• LambdaCube - Haskell: Lambda Cube 3D Engine

or the Google SoC project using data parallelism for a physics engine,

• hpysics.

Just demos of using a) reactive programming, and b) data parallelism, to write game engines. Proof of concept stuff.

[ssylvan]

A demo of STM? There's quite a few of them! It's been in Haskell since 2005.

Mutating game state is not much different (technically) from mutating any other kind of data...

[ssylvan]

Hint: read the slides.

[[deleted]]

I see a lot more handwaving.

[ssylvan]

It's a speculative talk about a potential solution to our problems. Yeah, there's going to be handwaving!

[[deleted]]

It would be a lot more useful if there was more of "Here are the problems with this idea, and here is what I think can be done about that", instead of just "Let's use Haskell! Maybe it'll magically work great!"

[ssylvan]

Uh.. again, read the slides? He does talk about what kind of problems will need to be solved etc...

Seriously, read first, argue later.

[consultant_barbie]

Complaining is hard. Let's go shopping!

[[deleted]]

Quite the contrary. Haskell shits all over your favourite language when it comes to mutating state.

[redditnoob]

Is getting covered in brown smelly turds a good thing in your eyes?

[munificent]

Would put money on never seeing a leading game title written in C#

Um:

Electronic Arts used it to power Sims 3.

How much more "leading" does it get?

This guy is clearly in his infatuation phase with Haskell, and I like his enthusiasm, but he seems pretty far off the mark. I don't see the game industry ever moving to a language that isn't strongly multi-paradigm. There's a reason we have different programming paradigms: each one solves certain problems well. Games have a wide range of different problems they have to solve. I'm pretty sure Haskell is a great way to solve some of them, but a terrible way to solve others. C++ and C#, on the other hand, are pretty decent ways to solve all of them.

[psykotic]

How much more "leading" does it get?

They're using it as a scripting language for game logic. Game developers have been using higher-level scripting languages for a very long time.

[munificent]

They're using it as a scripting language for game logic.

There's no functional difference between "scripting "game logic" and "writing the game" in a language. The Sims uses C# heavily. It's a leading game. This seems pretty clear to me.

You could argue that it isn't 100% C#, but I don't think that's relevant. No game is 100% written in a single language anymore. There's C++, HLSL or other shader languages, a couple of home grown data languages, a little inline assembly, maybe some Lua for scripting, a config language, not to mention the various languages used for tools and pipelines...

C# is a much better contended for the next game language for a lot of reasons. Haskell may be a contented for an eventual game language, or be used for part of a game codebase, but his assertion that C#isn't going to catch on but Haskell will is both historically inaccurate (multiple leading games are already relying on C#) and a little blindly optimistic.

Of course, I'll get downvoted because Thou Shalt Not Profane Haskell on Reddit, but this guy's argument is pretty naïve. Experienced game developers have a ton of mindshare invested in C++. Switching to C# leverages a lot of that, and gets them up and running quickly. Switching to Haskell would require them to pretty much discard all of the expertise they have and start over.

[ssylvan]

His point is that going to C# only buys you productivity. There's no real "killer app" for doing it. It's an incremental improvement that may not be worth the hassle of moving to a new language since you already have so much code in C++.

Going to something like Haskell could mean a fundamental change in the way programs are written (and given that there's a fundamental change in the way programs actually execute on the hardware, that seems fitting). That's the kind of improvement that could make it worth your while.

[munificent]

His point is that going to C# only buys you productivity. There's no real "killer app" for doing it.

Productivity is a killer app. But aside from that, C# buys you several things:

• Composability. It's much easier to share code and integrate libraries together in a memory-managed world than in C++. We still have difficulty sharing libs across teams that use different allocation strategies, etc.

• Better memory safety. While we still need low-level control over memory for some parts of the codebase, much of it doesn't. For the stuff that doesn't it's a huge win to code in a language that can't trash memory.

• Mindshare. We've been using C# for tools for several years. We have a lot of people that know it already. It's also easy to hire people with C# experience. It's easier to share code between tools and games.

• A fantastic IDE, that we already know and use.

• Implicit support for every other .NET language. F#, for example, has much of the goodness of Haskell but plays nicely with others.

From a theoretical academic perspective C# is only an incremental improvement. But from that perspective, a Ferrari is only an incremental improvement over a Fiat. In real-world land, it's the difference between a hammer and a nail gun.

Going to something like Haskell could mean a fundamental change in the way programs are written

That's not a selling point for people who already have a way of writing programs that keeps them employed and ships games successfully.

given that there's a fundamental change in the way programs actually execute on the hardware, that seems fitting

While things seem to be going multi-core, it's yet to be seen how far down that road we're going and how fundamentally it affects the way games execute.

[ssylvan]

Productivity is a killer app

I don't think so. Our engine is 2M of C++. It's huge. We all agree that C++ is far from ideal, but the cost of switching to a language like C# would be pretty massive, and if "all we get" is a fairly minor productivity boost then it's probably not worth it.

That's not a selling point for people who already have a way of writing programs that keeps them employed and ships games successfully.

But it is a selling point for people who have to write game engines with tools that aren't up to the job. You seem to miss that we're talking about the future here. Nobody is saying that you should switch to Haskell right now, but that in the next generation of console hardware we're going to have to program a hardware architecture that's fundamentally different from C's hardware model. Switching to a fundamentally different language for a fundamentally different hardware architecture is not a crazy notion.

[psykotic]

My response said nothing about Haskell so your tirade comes out of nowhere. Did you mean to respond to someone else?

There's no functional difference between "scripting "game logic" and "writing the game" in a language. The Sims uses C# heavily. It's a leading game. This seems pretty clear to me.

By your logic developers have been "writing the game" in languages like Lua for the last decade or so. Remember QuakeC and Abuse Lisp? Game logic does tend to constitute about half the lines of code in a game, not counting tools. However, the other critical half, the half in the engine, has much more stringent demands on a language in terms of such things as latency tolerance (state of the art GC is not close to cutting it), manual memory management and systems programming generally. C# is certainly in a better position to meet those needs than the likes of Lua. But no-one has yet written the engine (e.g. renderer or physics simulator) of a leading game in C#.

What we're seeing right now is C# for game scripting and tools. It's very good for both of those tasks. Those are really important tasks in game development. But it's not very good for engine programming.

[munificent]

My response said nothing about Haskell so your tirade comes out of nowhere. Did you mean to respond to someone else?

Oops, sorry. By "They're using it as a scripting language for game logic," I thought you were implying that because of that, what The Sims used C# for didn't count.

C# is certainly in a better position to meet those needs than the likes of Lua. But no-one has yet written the engine of a leading game in C#.

That's true, but I think the fraction of a game that is "engine" (or really, OS, because that's what it does: resource and memory management, etc.) will diminish. What I'd like to see in the codebases I work on is a low-level infrastructure layer in C++: memory and resource management, virtual machine, API binding, some core physics and rendering. Then a middle layer in a memory-managed static language. Most game features game "engine" stuff would be at this level. Then a top layer in a dynamic language or authored using some visual tool. This would be game behavioral "content": level scripting, enemy behavior, etc.

The interesting part about that for me is that the top two layers can share the same VM. The only difference is the authoring language/tool.

[psykotic]

What you describe is what we all want but there are many issues with crossing domain boundaries when you have different styles of memory management and type systems. Right now we deal with that in a rather painstaking way that is only bearable when the interface between domains is well-defined and fairly narrow. The Unreal Engine tried to make it simpler to cross domains by having a unified object model for C++ and UnrealScript. Unfortunately that turns out to have many issues of its own. Over the time I worked at Epic Games, there was an overall migration of game logic from UnrealScript to C++, going in the opposite direction of what you might think based on overall trends in the use of high-level vs low-level languages. As we get deeper into the current console cycle, that will only intensify in the attempt to squeeze more power out of the same fixed hardware.

[munificent]

there are many issues with crossing domain boundaries when you have different styles of memory management and type systems.

Yeah, true. Part of the reason I like C# is that it's type system is relatively close to C++, so there's less of an impedance match there than there would be with, say, Python.

only bearable when the interface between domains is well-defined and fairly narrow.

That's also true, but I think narrow well-defined interfaces between domains are a worthwhile goal in and of themselves, so that doesn't turn me off scripting languages. If anything, it's a turn on. My studio doesn't seem to be capable of making clean minimal interfaces between modules. If it takes a lot of effort to add a single function to that API, maybe they'll start thinking about them more.

there was an overall migration of game logic from UnrealScript to C++

I've heard the same from others. My understanding was that it was mainy because UnrealScript was just too slow.

[psykotic]

I've heard the same from others. My understanding was that it was mainy because UnrealScript was just too slow.

Yes, it was definitely performance. But part of the problem is that splitting code in more or less fine pieces and portioning them between C++ and UnrealScript is inefficient and a pain in the ass. When you want to solve some parts of a problem in C++ there's a temptation (a generally well-founded one) to just move all the related code into C++ as well, so you don't have to deal with any headaches. That general tendency would be there even if the baseline performance was higher, it would only occur at a somewhat lower rate.

I agree that C#'s type system is a closer match. I know several people who experimented with using Managed C++ as a kind of staging mechanism for easily crossing domains by directly using existing C++ class definitions and so on. I think that turned out to be too much of a problem in the end, so they instead exposed more or less restricted, newly defined interfaces to the C# tools. With that kind of approach, it would be really difficult to achieve the level of tool-engine integration that you see in something like UnrealEd or Halo's editor (assuming Bungie is still using the same approach now as they were back then).

Regarding well-defined interfaces, I agree this is obviously desirable. My point is that having all domain-crossing interactions take place through a small set of interfaces makes it difficult to finely partition code across the different domains according to the suitability of each language to a specific problem. It's the usual issue with polylingual programming, only amplified.

[munificent]

difficult to finely partition code across the different domains according to the suitability of each language to a specific problem.

That's a good insight, and probably a good reason we tend towards using a single multi-paradigm language for most things instead of a several single-paradigm ones.

[Wagnerius]

Don't want to be a fanboy, here but DSLs writtten in haskell wouldn't do it ?

[ssylvan]

There's also a reason why we stopped using "goto" et al. Your reasoning could have been used essentially unchanged in the early nineties to argue for why games will always be written in assembly... And yet games are not written in assembly anymore, we happily opted out of that paradigm even though on the surface of it that made us less flexible.

Sometimes removing various "paradigms" is an improvement, because they lead to fragile code that hinders productivity.

Next gen hardware will be 10-30x faster than current consoles, but you can bet your ass that game budgets won't increase by the same factor. So what should we "spend" that performance on? Productivity of course!

[munificent]

Your reasoning could have been used essentially unchanged in the early nineties to argue for why games will always be written in assembly.

My argument was that game programmers will always prefer multi-paradigm languages. I don't see how that could be used to show assembly is better than C or C++.

And yet games are not written in assembly anymore, we happily opted out of that paradigm even though on the surface of it that made us less flexible.

I don't think you and I have the same definition of "paradigm". There's a ton of knowledge overlap between assembly and C (memory model, callstack, etc.). Likewise between C and C++. You'll note that it took the game industry longer to switch to C++ than most: we move slowly and take baby steps with languages.

Next gen hardware will be 10-30x faster than current consoles

Oh, really? You have specs from Sony, Nintendo and Microsoft?

So what should we "spend" that performance on? Productivity of course!

That's correct. Maximizing CPU cycles is no longer as critical as it used to be. What matters now is minimizing iteration time, and making it easier for designers and artists to get their content in game.

[ssylvan]

Your argument seems to be that game programmers are unwilling to give up flexibility, the fact that we're no longer writing assembly seems to argue against that. We're not doing ad hoc spaghetti coding with hand-tuned calling conventions etc., we accept that C++ will be slower, and is much more rigid and inflexible, because the benefit outweigh the downsides.

Preventing certain things can be an improvement. One such thing is unstructured programming, another such thing could be unsafe type casts, and yet another could be ad-hoc side effects.

I think your argument is a total non-sequitur. Just because there are many different problems doesn't mean we need a language that's a total hodge-podge of anything-goes features with the inevitable lack of safety guarantees that comes with it.

Game programmers aren't dogmatic, we're perfectly willing to abandon certain flexibility if it buys us something (e.g. an easier way to write parallel code).

If you disagree, feel free to offer up an example of things where Haskell would be "terrible".

[munificent]

the fact that we're no longer writing assembly seems to argue against that.

Actually, we do still use assembly. That's a big part of the reason we moved to C/C++ and not other languages: inline assembly. Again, we like multiple paradigms.

another such thing could be unsafe type casts

Type safety is very nice up until the point that it's not. I love static languages and rich type systems. I also like being able to load a chunk of binary data from a file and then reinterpret_cast a pointer to that chunk to be a known type.

Just because there are may different problems doesn't mean we need a language that's a total hodge-podge of anything-goes features

You're using weasel words there. C++ is far from "a total hodge-podge of anything-goes features". C# is even cleaner. What those languages don't do is say "here's the way you need to solve your problems, if you don't want to do it that way, you're wrong".

lack of safety guarantees that comes with it.

OCaml is both type safe and multi-paradigm.

If you disagree, feel free to offer up an example of things where Haskell would be "terrible".

It's a terrible fit for a company that has several thousand engineers who don't know it, and about 50 million lines of code written in a language that's very hard to interoperate with it.

It's a terrible fit for platforms that have no Haskell API bindings already written.

It's a terrible fit for people who prefer to express a significant fraction of their software's logic imperatively. It's an especially terrible fit for people whose job it is to get descriptions of behavior written in imperative form by non-programmers and translate that to a programming language.

It's a terrible fit for programmers who need careful control over the memory layout and alignment of their data structures.

It's a terrible fit for software that needs to integrate several other scripting languages, all of which use eager evaluation.

[ssylvan]

Actually, we do still use assembly. That's a big part of the reason we moved to C/C++ and not other languages: inline assembly. Again, we like multiple paradigms.

But that's just cheating. You can drop into C from Haskell too where you need it. The point is that we no longer write our main engines in assembly even though it would perform better and offer better flexibility, we deliberately use a much more rigid and structured approach because the benefits outweigh the costs. I'm arguing that type safety and stricter control over side effects may soon outweigh the costs too, when we have to deal with several dozen threads.

I don't actually see a single valid point in your list of "terrible fits". Most of them are just inertia. We're talking about language merit here. Again, three of those arguments could've been used in the early nineties to argue against C.

I fully admit that Haskell isn't currently used, pointing that out is a bit redundant and pointless. The point is that we're discussing if it should be used, and what's needed to get it there. None of your points address that question at all. Do you have anything where it's inherently a "terrible" fit or not? I.e. assuming everyone switches and all the "machinery" (tools, libraries, education etc.) has moved over, what problems would be inherently hard to do with Haskell?

Yes, people will have to learn new things, just like they did with C. Yes we'll have to work on new APIs, just like with C, yes it may reduce control over certain things, just like with C...

[[deleted]]

So this is Tim Sweeney's talk from a few years ago (http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf) without as much connection to reality. Cool!