back

by zorked·15y ago·view on hn ↗
I suggest that you read the whole sequence of articles, particularly the ones where he tries to implement Pac Man in a purely functional way.

Keep in mind that he is an Erlang fan, and he is not trying to "debunk" functional programming. He's just toying with applying it to a domain where it's not used often (action video-games). The whole series is excellent, as is, in fact, the whole blog.

2 comments
Except that he doesn't try and implement it in a pure, functional way.

Every linked article discusses his adventures with Erlang. Erlang is a great language, one that I've used to great effect and enjoyed very much, but Erlang is really bad at representing rich type relations. The author is absolutely right that records are a painful substitute for dictionaries (a construct he reached for naturally because Erlang is a dynamic language).

He tried to implement it in Erlang's curious and somewhat isolated pseudo-functional rigid-actor paradigm. People have been making games and game-like demos in Haskell and OCaml for quite some time now (OCaml especially seems like very good fit). Erlang is a beautiful tool designed to solve one very specific set of problems. In its domain, it is nearly unrivaled. Outside of its domain, it is lackluster and limiting. It's only recently that modern functional programming techniques like monads and a cheap lambda syntax have started to make their way into Erlang (see Erlando: http://www.rabbitmq.com/blog/2011/05/17/can-you-hear-the-dru...), so it should be no surprise that someone writing in 2008 found a lot of awkward edges.¹

Am I wrong? I quickly scanned every linked article (and their follow-ups) and didn't see a single mention of anything but Erlang, including an all-too-common digression into using tuples as a dynamic substitute for algebraic data types.

¹ I can't help but feel like people assume most Haskell and OCaml programmers are chronic masturbators; making constructs like Monads and Functors because they just love category theory instead of the reality; building a functional pattern language on the same order as what Gamma, Helm, Johnson and Vlissides captured for OO programming.

His solution is the "problem" of having to update the whole game state in a function is "is not to return new versions of anything, but to simply return statements about what happened" and "Actually handling what happened is a separate step, one that can be done later on in the frame."

Did he just make an imperative DSL out of erlang?