Tetris in Haskell(lambdacolyte.wordpress.com)
lambdacolyte.wordpress.com
Tetris in Haskell
http://lambdacolyte.wordpress.com/2009/08/06/tetris-in-haskell/
22 comments
Presumably this is newsworthy because building Tetris in Haskell is harder than in an imperative/OO language? Why is that a good thing?
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.
FWIW, I would need a week and lots of help to do it in C, but I could probably do it in a few days with Haskell.
This says nothing about Haskell or C, but it does say something about me.
This says nothing about Haskell or C, but it does say something about me.
This is a blog about functional languages, so this man obviously knows a lot about Haskell but still required help for a game that would be prettymuch a hello world for someone in almost any other language.
I know nothing of your abilities, even so, if haskell is the only language you know well, I'd be impressed if you could make the game as fast as me or most ppl here.
I know nothing of your abilities, even so, if haskell is the only language you know well, I'd be impressed if you could make the game as fast as me or most ppl here.
The first paragraph of the post explains, "it’s my first, real foray into Haskell."
If your first real program in any language was a Tetris game, you'd probably need some help getting started too.
As shown by the various games posted elsewhere in this thread, there are perfectly trivial and straightforward ways to write games in Haskell. If nothing else, Haskell's "do notation" makes it easy to safely mix imperative programming with pure functional programming.
When people do post about writing a game in a new language as a notable achievement, it's usually because they did it in part to learn a new language (as in this case) or a new concept (like using FRP or Erlang-style message passing, instead of imperative programming with mutable state).
If your first real program in any language was a Tetris game, you'd probably need some help getting started too.
As shown by the various games posted elsewhere in this thread, there are perfectly trivial and straightforward ways to write games in Haskell. If nothing else, Haskell's "do notation" makes it easy to safely mix imperative programming with pure functional programming.
When people do post about writing a game in a new language as a notable achievement, it's usually because they did it in part to learn a new language (as in this case) or a new concept (like using FRP or Erlang-style message passing, instead of imperative programming with mutable state).
Sorry, I missed that sentence, yes you're right. I read the bit to the right of the blog and the blog title which give the impression that he was experienced with Haskell.
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
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.
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.
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.
What I can tell you is that the backend (which really needs no state) is much more easier to write in Haskell IMHO.
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.
this is a video of somebody playing tetris, it could have been programmed in java, haskell or brainfuck for that matter.
Without the code to go with it haskell hasn't got much to do with it. Would be nice to see the source!
Without the code to go with it haskell hasn't got much to do with it. Would be nice to see the source!
Yeah, the source code would be very good to see.
If it is programmed in brainfuck though I'm going to eat my hat or something. Do penance in a major way ;)
I'm afraid most brainfuck implementations don't have non-blockind IO; therefore, you can't.
Otherwise it would be very fun.
hm... time to get coding :)
maybe we can 'memory map' some of it ? Subsequent locations in memory that you plot to a screen on over modificiation (b/w would be ok in this case I guess), a bunch of bitfields that get 'latched' whenever a key is pressed that the brainfuck mainloop has to walk by every now and then, resets and uses as branching points ?
That should do it.
It doesn't need blocking io, see. Polling latched inputs is the way the machines of old did it, it's a bit less efficient but it works.
maybe we can 'memory map' some of it ? Subsequent locations in memory that you plot to a screen on over modificiation (b/w would be ok in this case I guess), a bunch of bitfields that get 'latched' whenever a key is pressed that the brainfuck mainloop has to walk by every now and then, resets and uses as branching points ?
That should do it.
It doesn't need blocking io, see. Polling latched inputs is the way the machines of old did it, it's a bit less efficient but it works.
There is an implementation of tetris in haskell with the source code: http://web.comlab.ox.ac.uk/people/Ian.Lynagh/Hetris/
I discovered it when a regular contributor contributed an article on the game to my FOSS gaming encyclopedia.
I discovered it when a regular contributor contributed an article on the game to my FOSS gaming encyclopedia.
Could you provide the link to the encyclopedia of yours?
There's a pretty big collection of games (of varying maturity and complexity) at the Haskell Wiki, including a couple of tetrises [1]. One of them, Frag [2], is a pretty cool 3D first-person shooter. It's one of the most popular current downloads from Hackage [3]. The source code [4] is well-factored and uses functional reactive programming (FRP) to model time and user input/output.
1. http://www.haskell.org/haskellwiki/Applications_and_librarie...
2. http://www.haskell.org/haskellwiki/Frag
3. http://donsbot.wordpress.com/2009/08/06/haskell-package-popu...
4. http://code.haskell.org/frag/src/ (Darcs 'get' enabled)
1. http://www.haskell.org/haskellwiki/Applications_and_librarie...
2. http://www.haskell.org/haskellwiki/Frag
3. http://donsbot.wordpress.com/2009/08/06/haskell-package-popu...
4. http://code.haskell.org/frag/src/ (Darcs 'get' enabled)