Presumably this is newsworthy because everyone assumes building Tetris in Haskell is harder than in an imperative/OO language. This is a good thing because it proves that it's not.
He says its taken him a week to do it and has had to ask lots of people for help. So I'd say its much harder than in a language like C#. I could (and so could most other people here) make tetris in 1-2 days without help.
Actually I never said it took me a week :P And I did ask for help because I was learning Haskell as I was implementing the game.
He says its taken him a week to do it and has had to ask lots of people for help. So I'd say its much harder than in a language like C#. I could (and so could most other people here) make tetris in 1-2 days without help.
But the thing is, functional game development techniques are nowhere near as developed or established as those of OO game development. The solutions to the problems at hand aren't as immediately obvious. This comes to mind: http://prog21.dadgum.com/23.html
All this hinges on the fact that functional languages are only now being appreciated: functional languages seem to be popping up like daisies now either via stand-alone languages such as F#, multiparadigm languages or even in OOP languages (I believe I read somewhere that C# is integrating ideas from the functional paradigm). Still I can't pretend that any functional language has so far become as remotely popular as say Java or C++. Due to this the work done on functional programming and games is quite a niche area which is often explored to do a fun project while learning a language.
But the thing is, functional game development techniques are nowhere near as developed or established as those of OO game development. The solutions to the problems at hand aren't as immediately obvious. This comes to mind: http://prog21.dadgum.com/23.html
You don't need to do anything non-trivial for imperative/OO game programming. If something non-trivial is required for functional programming, then it is more difficult.
As far as I know there is nothing non-trivial that I had to use apart from introducing state when it was needed by the game via monads and muteable variables. At first they were tricky because I was used to taking such things for granted.
What I can tell you is that the backend (which really needs no state) is much more easier to write in Haskell IMHO.