I have the slides available for review from scribd below. There’s plenty about agents and futures in there, plus a look at Evented IO in Node.js and tuple spaces with Rinda. After the break, I also offer a few observations about the content in light of questions asked in the meetup and my own reflections.
I’d like to thank Craig Andrea for asking a question I was primed to answer, about how Clojure’s agent serializes actions. The short answer is two-part: the agent’s ActionQueue member, which Russ Olsen called “A queue with an attitude” makes updating the list of pending actions atomic; and each action’s execute method can only be called in conjunction with the queue’s update. The long answer deserves a post of its own. Thanks to Chris Houser (aka chouser) for helping me understand this the day before my presentation.
Another attendee asked me about JavaSpaces, which would be a great way to explore tuple spaces and blackboard servers from Clojure. I couldn’t offer any expertise, though, since I hadn’t thought of it before. :-/
I called this out in the talk: the
future-call function in
clojure.core features a great use of
reify, a new feature in Clojure that lets you assemble an object for the Clojure and Java worlds.
reify also lets you specify that the object extends not only Java interfaces, but Clojure’s protocols. By implementing a
deref method for its return value,
reify returns an identity you can dereference without having to make future a fully-fledged ARef. By the way, Baishampayan Ghose has just published a nice post on protocols and deftypes.
I wish I’d had time to present EventMachine, (one of?) Ruby’s evented IO frameworks, but some things had to go. Thanks to Paul Barry for pointing me towards them and towards Mike Perham’s presentation about using EventMachine with Ruby 1.9’s fibers. There’s going to be a RailsConf presentation on Evented IO and fibers, and I will be all over that.
I also wish I’d had time to talk about measuring performance and parallelization, and about benchmarking and profiling. There’s less reason to embrace concurrency if it doesn’t give us a real performance boost. I also would like to address at some point the value of being able to reason about values and behavior when reading code, and the tension of this virtue with performance optimization.