Reactions to "Purely Functional Retrogames"
I just read this blog series on "purely functional retrogames" from six years ago, on the basis of a recommendation from my Twitter friend/occasional conference-co-attendee Scott Vokes . Things I thought were interesting points/good takeaways: It's better to nest state-keeping records deeply, rather than making wide/flat ones; never have more than a few fields to refer to, and you can pass around chunks at a time to different subroutines. Being forced to think out data-dependencies can be a good thing: [In a purely functional style], functions can't access any data that isn't passed in. That means you need to think about what data is needed for a particular function, and "thread" that data through your program so a function can access it. It sounds horrible when written down, but it's easy in practice. In fact, just working out the data dependencies in a simple game is an eye-opening exercise. It usually turns out that there are far f...