“A closure is a poor man’s object; an object is a poor man’s closure” (2003)

My definition of an object is "an ADT that gets to 'decide', using private runtime state, what to do in response to any/all attempts to interact with it." Which makes for a very simple test: if something is an object, you should be able to send it a message that makes it change its mind about what messages it accepts after that. There's no obvious way to implement a behavior like this using the native "objects" in nominally-object-oriented languages like…

One problem I've noticed with a very closure-heavy style is that debugging is a pain — you have a closure with a bunch of local state and no way to print or otherwise access it (from the repl, say). So then you end up writing special cases of the function for when the first argument is :debug... any better ways to do this?

This post had inspired me to write CljOS[1], an Object System in Clojure mainly because I wanted to write a game engine and had freshly arrived from the Java world. It turned out to be extremely straightforward to map objects to closures. Took <100 lines of documented code! obj.method(& args) => (obj :method & args) I even have a basic 2d sprite-based game engine here[2] (on top of Swing!). [1] https://github.com/divs1210/cljos [2] https://github.com/divs1210/bakait

I invoke the ko rule... Situational Cycle: a move sequence that starts and ends at the same position such that at the end of that cycle it is the same player's turn as it was at the start. If cycles are allowed without restrictions on them, it is possible for a game to go on indefinitely. [1] The 'ko' situation is the most common cycle that occurs in the game of go. Ko: a situation where two alternating single stone…