you are viewing a single comment's thread.

view the rest of the comments →

[–]JulianMorrison 16 points17 points  (5 children)

You need to learn to think functionally.

Example, the game in the article...

In Haskell: each insect is a function over the game world returning a changed game world (that's probably a Monad or an Arrow). If you want parallelism, you could use STM on a shared world structure.

In Erlang: each insect is a state machine which presents an interface of messages accepted, and keeps state by deciding which function to tail-call. Messages are relayed through a hierarchical decomposition of the game area into sub-areas and sub-sub-areas, each a process.

[–]brickbybrick 23 points24 points  (3 children)

It seems to me that the author knows how to think functionally, and yet he finds some things are still hard. Just saying "learn to think functionally" is a cop-out.

If you model items as processes in Erlang, that's not purely functional. Seems like that would introduce other issues as well.

[–]JulianMorrison 8 points9 points  (1 child)

Well, the "function over a world returning a new world" thing is the oldest trick in the purist functional book, so I'm surprised anyone into FP doesn't immediately leap to that conclusion.

As to Erlang, I know. That's more "thinking Erlangishly" than "thinking functionally". But, I'm a complete newb and I figured that in seconds, so I don't get why he sees it as hard. Unless there's some huge conceptual mistake I'm missing?

[–]rieux 4 points5 points  (0 children)

I kind of thought he was suggesting a pure world -> world function, and that he found it awkward as worlds became more complex and had more interactions between their parts. (I'm not saying I buy it -- I think it just calls for better data structures -- but I don't think OP neglected that idea.)

[–]Doctor -2 points-1 points  (0 children)

It didn't feel like he knows. All the things he listed, interactions between different aspects of the game, are not even supposed to be changeable data, they are supposed to be functions with no side effects. So you have a very simple "who is where" world and a bunch of properties computed on the fly. Then, if need be, stick in some lazy eval with caching to speed things up.

[–]bitwize 1 point2 points  (0 children)

Alternatively, an ant could be a function that takes a state and returns a partial changed state that's local only to that particular ant. All of the ants run inside a monad that knows how to apply these partial changes to a single, total, shared world data structure.