Hacker Newsnew | comments | show | ask | jobs | submit login

I like these posts, the presentation is quite good IMO.

You see the old game state --> new game state pattern a lot in functionally written games, but something about that has always seemed off to me. The functional retrogames series of posts (starts at http://prog21.dadgum.com/23.html ) summed up the issue well I think,

When I first mused over writing a game in a purely functional style, this had me stymied. One simple function ends up possibly changing the entire state of the world? Should that function take the whole world as input and return a brand new world as output? Why even use functional programming, then?




Why does taking the game world as an input seem so odd? Thanks to Clojure's structural sharing "returning a brand new world" can be efficient.

Judging from later parts of James Hague's series, he was working with Erlang which doesn't seem to have this feature. He also complains of lacking a good map structure — not a problem with Clojure.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: