Quick update – Games, Reality, and Haskell

It had been a little while since my last post, so I wanted to just jot down some stuff I’ve been doing lately.

First, in order to learn Haskell, I started working though Haskell’s 99 Questions, which is a series of short functions of increasing difficulty.  I have my solutions hosted on my github repo.

The other thing I have going on is I’m reading Jane McGonigal’s Reality Is Broken.  The book leverages a lot of research in positive psychology to argue that games (the book takes the slant of video games, but really any kind of unnecessary obstacle activity such as rock climbing) are “better” than reality.  The basic argument of the book so far is this: if modern psychological research shows us that people are in their happiest and most activated state when playing games, then why must we endure our normal lives?  Why can we not use the best aspects of games in igniting human happiness and incorporate them into our societies to improve the quality of life of everyone?

I’m less than 100 pages in so far, and I have mixed feelings.  The book does a pretty good job of highlighting interesting findings in positive psychology, and the points made in that regard I feel are spot on.  I would read a short paragraph and think to myself, “You know…you’re right.  That *does* make my happy.”  On the other hand, I think the book really stretches to apply the research findings to the field of video games.  The author, being a game designer, clearly has a bias in this sense, but that also drives her passionate prose style.  She spends a lot of time explaining the mechanics of certain video games like SMB 2 and Tetris, but then fails to really drive home her point that video games are the ideal medium in which to engineer human happiness.  It’s almost like she thinks it is self-evident that games and positive psychology go hand in hand.

Again, I’m only a little ways in, so maybe I’m trying to jump ahead to points she makes (or doesn’t make) later.  I just learned recently that my good friend Seth read this book and wrote a paper on it for a class, so I’m eager to chat with him about it.

Understanding Monads in Haskell

Update: I started reading up on monads again recently, and here is the best explanation I’ve found.  Also, the update caused my Beckman links to vanish unfortunately…

I’ve been digging through the Haskell resources I posted earlier (and some other ones ), and I must say that treatment of  monads has been pretty poor.  There are all kinds of cognitive metaphors out there, the least clear and most ridiculous of which has to be the space station analogy.  However, I think after seeing a few key resources the picture is starting to come together.

First is a great pair of videos from Microsoft’s Brian Beckman.  It’s geared toward concurrency, but he talks about Haskell’s State monad as a way of automatically mutating an explicit (vs implicit) state.  Doing this non-monadically would mean passing in the current state into each function, but with monads, you can construct larger operations by composing the monads together, and the monads will handle all the work of passing around and updating the state.

The videos are pretty long, but quite interesting and really help to introduce the way a particular monad (the State monad) handles compositing.

The next resource is Monads as a computation. This page generalizes the concepts introduced in the videos. Essentially, monads a way of describing how computations are chained together to form more complex computations. The logic of what happens between computations (such as pre- and post-processing) before moving on to the next step is built into the monad (specifically the return and >>= functions).

Lastly, Learn You a Haskell (which, incidentally, I’m beginning to like more than RWH as the concepts get more sophisticated) has a chapter on monads, which goes in to how Maybe and List monads handle their own processing between steps. For instance, if at any point in a Maybe monad chain Nothing is the result, then that Nothing is propagated to the end of the chain (canceling later computations on the way).

From my understanding of monads (so far), they are a convenient way to automatically handle any book keeping that needs to be done between successive operations (Writer monad, which can be used to log all operations performed) or for controlling the flow of operations in a standardized way (aborting operations with Maybe, handling list flattening with List).

Resources for learning about Haskell

As my last post alluded, I’ve started to dive into the world of functional languages.  I chose to go with Haskell over Scala since Haskell is allegedly the most “pure” of the functional languages in use, and I am of the mindset that I should go big or go home.

I’ve started to read a lot about Haskell lately, and do a few toy examples to try to solidify the concepts more.  In my reading, I have come across some good resources.

The first and I think best resource I have found is Real World Haskell.  It goes through Haskell concept quickly with an appropriate amount of dumbing down.

Similar to RWH is Learn You a Haskell for Great Good.  If you find the style of RWH a little too formal, then Learn You a Haskell is for you.  I thought Learn You a Haskell’s style a little charming at first but then rather annoying, so I recommend RWH.

I am still learning about monads, but I think this resource is decent What the hell are monads?.

And then, if you want to know more of the pros and cons of using functional languages (Haskell in particular) I would direct you to a slashdot discussion on the topic as well as this rather recent blog post.