4 ms·

I stopped reading when I got to this gem: "It can be done quickly and cleanly by adding some global variables." We differ by orders of magnitude on what const

by diolpah 15y ago

I stopped reading when I got to this gem: "It can be done quickly and cleanly by adding some global variables." We differ by orders of magnitude on what constitutes 'cleanly'.

zorked 15y ago
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.
- KirinDave 15y ago
  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-drums-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.
- ldar15 15y ago
  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?
pessimizer 15y ago
He's talking about the smallest and simplest of global variables in that quote, hence: "it's completely doable to write [Pac-Man] in a purely functional style. The dependencies can be worked out; the data flow isn't really that bad. It still may be a messy endeavor, with lots of little bits of data to keep track of, and selectively moving parts out of the purely functional world will result in more manageable code. Now the obvious target is either the state of Pac-Man himself or the ghosts, but those are part of the core data flow of the program. Make those globally accessible and modifiable and all of a sudden a large part of the code has shifted from imperative to functional...and that wasn't the goal." meaning that trying to make Pac-Man or ghosts into pieces of mutable state will result in them being manipulated entirely by being passed between functions, an even more functionally tangled program (in terms of less being able do some modifications to it as easily as could be done in a similar imperative program.) Instead he's suggesting adding tiny self-managed globals for little values that truly are global (used almost everywhere) but aren't constant. Basically segregating tiny pieces of mutable state into their own little cubbyholes in order to simplify the logic. Or at least that's how I'm reading it.
- weavejester 15y ago
  "Instead he's suggesting adding tiny self-managed globals for little values that truly are global (used almost everywhere) but aren't constant. Basically segregating tiny pieces of mutable state into their own little cubbyholes in order to simplify the logic." That kinda sounds suspiciously like a monad.
  - pessimizer 15y ago
    kinda does...
  - j_baker 15y ago
    It also sounds suspiciously OO.

by diolpah 15y ago

I stopped reading when I got to this gem: "It can be done quickly and cleanly by adding some global variables." We differ by orders of magnitude on what constitutes 'cleanly'.

zorked 15y ago

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.

KirinDave 15y ago
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-drums-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.
ldar15 15y ago
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?

pessimizer 15y ago

He's talking about the smallest and simplest of global variables in that quote, hence: "it's completely doable to write [Pac-Man] in a purely functional style. The dependencies can be worked out; the data flow isn't really that bad. It still may be a messy endeavor, with lots of little bits of data to keep track of, and selectively moving parts out of the purely functional world will result in more manageable code. Now the obvious target is either the state of Pac-Man himself or the ghosts, but those are part of the core data flow of the program. Make those globally accessible and modifiable and all of a sudden a large part of the code has shifted from imperative to functional...and that wasn't the goal." meaning that trying to make Pac-Man or ghosts into pieces of mutable state will result in them being manipulated entirely by being passed between functions, an even more functionally tangled program (in terms of less being able do some modifications to it as easily as could be done in a similar imperative program.) Instead he's suggesting adding tiny self-managed globals for little values that truly are global (used almost everywhere) but aren't constant. Basically segregating tiny pieces of mutable state into their own little cubbyholes in order to simplify the logic. Or at least that's how I'm reading it.

weavejester 15y ago
"Instead he's suggesting adding tiny self-managed globals for little values that truly are global (used almost everywhere) but aren't constant. Basically segregating tiny pieces of mutable state into their own little cubbyholes in order to simplify the logic." That kinda sounds suspiciously like a monad.
- pessimizer 15y ago
  kinda does...
- j_baker 15y ago
  It also sounds suspiciously OO.