Every single discussion board for developers has a thread called Functional programming vs rest of the world where you could read that Haskell/LISP/Scala/etc is much, MUCH better than C++. But when you ask about AAA games coded entirely in Haskell you get just silence.
Today I've been reading topic about exceptions in C++. One of the arguments against not using exceptions is that when you use return codes for errors you have to pass real results in arguments, like:
int OpenFile(const char *filename, Handle *handle);
Handle h;
if (SUCCESS == OpenFile("file.txt", &h))
{
// ...
}
And that doing so makes code "less clear" because you can't see what is input and what is output of function -- and you should return output ONLY as return value.
But we should go deeper: OOP is out of question (because method call can modify internal object state) and so are pointers (bacause you could modify something far away from local scope). Now we only need to get rid of variables (as all of our &variables& are constant) and voila! We have Haskell. :)
Let's assert that this style of coding is cool -- so why does nobody code games in Haskell?
Well, I think that functional programming lovers forget that computer program is composed like this:
1. Read input
2. Process input data into output data
3. Write output data
And functional programming is useable only in part 2. Input/output doesn't fit functional programming anyhow. If that parts are simple (like read N numbers from file, process them and save M numbers into another file) we could ignore it. But if it's gamedev, part 1 (reading player/network input) is important, and part 3 is VERY important (like rendering, sound, network communication etc). Part 2 is quite simple or sometimes even trivial -- so why should we need FP for it?
On the other hand, FP is good for example in shaders. GLSL/Cg/HLSL mimic C syntax, but they are overall quite functional. Pure data transformation (input interpolators -> fragment shader -> output colors/data); no external routines; no memory management; massive parallelism. So its just a matter of proper tool for given job.
Comments:
-
Xion:
Part 2 is nowhere near trivial, partially because it's closely tied to part 3 for performance reasons. And shaders are only trivially functional (in a sense of being 'pure' functions) with no typical FP concepts (like higher-order functions, currying, "infinite" data structures, etc.).
So while I agree with your statement about FP not being useful at game development, I'd advise to get your facts straight. Besides, I doubt FP has gamedev as one of its intended fields of use.03.10.2010 20:03:01
-
That's, like, totally wrong.
First and foremost, there is no 'input', 'process' and 'output'. All of these three are actually data transformations - no more, no less. The process you refer to as 'rendering' is in the end the transformation of the scene to a grid of pixels. It can be subdivided further, i.e. scene -> batch list -> gfx command buffer -> vertex/pixel vectors -> pixel values. Or even further.
Then, there is a difference between pure functional languages and functional languages. Of course, pure functional languages are not suitable to game development (and, imho, to most real problems - though that may be an imperative programmer inside me speaking). There are some elements of functional languages in modern languages, that can be used to great value.
Finally, the worst part about pure functional languages is not the input/output problem (which can be solved by some hand-waving, see Haskell monads), but the inherent inability to mutate data, which often leads to suboptimal algorithms for data transformation.03.10.2010 21:33:04
-
Biovf:
I second the "like, totally wrong" sentence by asking if you've ever heard of Naughty Dog? Well that "little" studio made all of their games before being bought by Sony with a Lisp dialect called Gool and then an evolution of it, called Goal.
Those dialects only produced unknown games like Crash bandicoot and the entire Jak and Daxter series, probably nobody ever heard of them.
http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
http://ynniv.com/blog/2005/12/lisp-in-games-naughty-dogs-jax-and.html
After that, I think that you're confusing several things, some of them pointed by Arseny, but what I think that you're confusing even more is: It is a fact that most functional languages present features that are lightyears of what we have in C+ (Yes I code in C ), and if you think otherwise, well...you're wrong.
If you know anything about language design, compilers and if you ever dared to look beyond the small world of C/C , you'll see that many languages are so much better than what we use in games...and here enters your argument about "Why doesn't anyone uses them?" (I have already showed that's not true but nonetheless), well if you work in IT, you'll see that half of the telecommunications world is run in Cobol and shit even older, I wonder, why is that? Shouldn't they update to C /Java??
Well yes but that costs money, is slow, there's tons of legacy code, etc etc
Lastly, I would like to point out that one of the biggest supporters of Haskell is, in fact, a man called Tim Sweeney. If you haven't ever heard this name he's "just" one of the founders of Epic Games.
Btw , C# 4.0 introduced loads of functional features in the most recent version, like lambda functions, I guess that also should mean something :-)03.10.2010 22:55:14
-
About GOAL (yes -- I admit I didn't hear about it before), quoting Wikipedia:
"GOAL encourages an imperative programming style: programs tend to consist of a sequence of events to be executed rather than the functional programming style of functions to be evaluated recursively"
So really -- what's the big deal behind it? I mean how is using functional language for imperative programming superior to using imperative language like C for imperative programming? From what I've read they had had more powerful IDE/debugging tools, but I guess that after 15 years it's not important anymore.
@Tim Sweeney
Sure, I've even read ''The Next Mainstream Programming Language: A Game Developer’s Perspective''. But so what then? AFAIR they never implemented any functional language into Unreal Engine.
@ C# 4.0
Well -- lambdas have been introduced even earlier (with C# 3.0 and LINQ). And yes, they are quite good at slowing down loops ;) And C+ 0x has lambdas as well.03.10.2010 23:22:39
-
Xion:
Every self-respecting language has lambdas and query sublanguage by now. Apparently most of the useful tenets of functional programming was absorbed into imperative. I guess it's quite similar to OO ideas leaking from Smalltalk to "more mainstream" lamguages: not everything was borrowed, but the useful and not-so-purist's concepts were.
04.10.2010 23:03:39
-
ix:
Blah blah blah... learn first -> then comment. Everything you've written proves that you really have no idea what the FP is. Learn about FRP and stop blaming technologies for your incompetence... It's so pity of you. Yet Another C++ - Maniac...
12.10.2010 18:30:09
-
And your comprehensive comment convinced me about superiority of FP over C+ . Totally! :)
12.10.2010 20:05:45
-
Reg:
I've seen a great sentence on Twitter recently:
"Functional Programming is dumb reason 1: it fails to take into account the way that _either_ computers or humans operate. Pick at least one."01.11.2010 16:50:14
