I appreciate this article for demonstrating Haskell optimization techniques. But honestly, I kind of expected a 3D game with impressive graphics to finally prove FP can used for these purposes. This is just a Breakout clone that runs below 30fps on Android.
back
3 comments
Yeah, it seems real impressive until you realize that you could duplicate it, faster, with only a small bit of C or C++.
Until I see a real-time software rendering project in Haskell doing full 3D, don't really think it's worth half the fanboyism it gets.
I have to agree. I wanted to see something spectacular and I wanted to see Haskell explored as a real option. But running 25fps on Android?! Seriously? It can't hit 30fps or today's accepted video game speed of 60fps on an extremely trivial Breakout game?? As I was reading, all I could think was that ONLY after a lot of optimizations requiring hacks or deep knowledge of how Haskell operates you hit a low slightly higher but still low benchmark..that's.. nice(?). Not the 'Wow, I should start using Haskell' argument at all.
I don't need to see full 3D to convince me, but the average game on any platform is tens to hundreds of times more asset-heavy, resource-heavy and computation heavy than this example. It's just not convincing to see it perform UNDER the expected 30-60fps.
So, the reason I mention full software 3D, is this:
Computers are, at heart, numerical engines. 3D rendering, in software, is the perhaps the purest form of exploiting that. If your language can't do that well, then it's a high-level language and is suited for gluing stuff together. I specify software 3D because any fool can pull in some OpenGL bindings and talk about framerates, but in that case their language is only glue for hardware APIs.
And there's nothing wrong with that, mind you, but then you can't get by on "But think of the performance this could have, one day, with magical compiler technology from the futuuuuuure!". You have to get by only on claims of safety, or developer ergonomics, or provability, or something else.
That's because you seem to be focused on extremely performance-sensitive coding. The vast majority of code out there is not that performance-sensitive. This is a big part of where your perceived "fanboyism" comes from. In this domain Haskell's vastly higher level abstractive abilities, safety, code conciseness, etc are light years beyond what C and C++ have to offer.
I believe functional programming does have its place in games and graphics, but I don't think it should completely replace imperative/OO programming (yet). Some aspects of game/graphics development map better to OOP (e.g. graphics apis) and should be handled with such tools.
I think, for now, a hybrid OOP/FP approach would be best. Right now, I'm prototyping a game engine in F# and C# to see if one could be viable. Incorporating FP has definitely simplified and allowed me to reason better about parts of code but I'm not sure if the tools and languages work well with each other enough yet.
Also see [0] for some thoughts about FP and game development.
[0] - https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...
Do you know about LambdaCube, for example?
http://lambdacube3d.wordpress.com/2012/09/08/some-eye-candy/