or learn more

Clojure Conj 2011 – Learning more pt.1

Feb 1, 2012

By my measure, the second Clojure Conj was a smashing success. I wrote summaries of the mainline Conj activities and the unconference activities if you need some context. The amount of brain power on tap at the conference was intoxicating. In an attempt to present a feel for the topics of discussion in the lecture hall and hallways I’ll post with links to posts, papers, presentations, and tidbits of information for learning more.

I’ve limited the scope of this post to cover only the initial released talks, but as more are released so too will I post more.

Learning Clojure – Next Steps

Stuart Sierra started the conference with a talk about pushing Clojure and ClojureScript further, including:

  • Extending the Clojure reader
  • Using Clojure from Java
  • Using the JVM’s base concurrency primitives
  • Using Clojure’s rich data-structures instead of JSON
  • And others…

From this talk there are a couple of interesting follow ups at your disposal. First, the idea of using Clojure’s rich data formats as a replacement for JSON was a topic of discussion during my DevIgnition talk on December 2nd, 2011 entitled *Code as data as code. The slides are only partially helpful, but I hope that a video will be available soon. In any case I will likely explore this idea in a later post. Second, the idea of an extensible Clojure reader via tagged literals was discussed deeper in Rich Hickey’s keynote at the Conj and is currently under design and implementation.

Concurrent Stream Processing

While Clojure’s official fork-join story is incomplete, David’s talk discusses Revelytix’s approach to concurrent data stream processing in their query processing engine. With a bevy of nice images, he walked through the high-level architecture of a system designed to combine large data streams as one might connect the ends of hoses. Related to this point, and of critical importance to Clojure, is the focus on leveraging topnotch Java libraries in achieving their goals. The near-seamless Java interop in Clojure is an incredible boon to companies and individuals using Clojure in their projects.

One of the interesting aspects of David’s talk was his discussion of how he and his team discovered ways to improve the design of their system, specifically how they might refactor protocols to split orthogonal concerns. This kind of thought-process and its benefits was recently summarized beautifully by Steve Losh on Hacker News.


Anthony’s talk on his Clojail library that provides a sandboxed environment for Clojure execution has a long and storied precedent. For example, Racket’s sandboxing capability is at least superficially very similar to Clojail. However, Racket’s runtime security mechanism called Custodians are very different from the JVM model absorbed by Clojail, although the goals for each are similar.

Before Racket (and PLT-Scheme on which it’s built) there was some research an implementation for Scheme48 of a security kernel by Jonathan Rees called W7.1 The approach of W7 is quite breathtaking and there may be some lessons to take away for Clojail itself.


Chouser’s presentation on ClojureScript was given on a nifty little piece of presentation software written in ClojureScript named Traction. This is just an interesting aside.

Data structures

In his talk he talked about how ClojureScript’s data structures are currently copy-on-write, mimicking Clojure’s behavior below a certain threshold. Reading over Clojure’s implementation of PersistentVector and PersistentHashMap provides some insight into this approach.

Protocols and types

Clojure’s approach for implementing types and protocols is built on the pseudo-classical inheritance pattern that stands in contrast to the functional inheritance pattern espoused by Douglas Crockford. Crockford’s pattern isn’t exactly Crockford’s pattern at all, but instead has a rich history. Some interesting implementations using this pattern to create class-based OO models include:

Extending JavaScript Libraries from ClojureScript

I enjoyed Kevin’s talk very much as his humor and wit shone through in his talk. Kevin’s company Keming Labs was one of the earliest adopters of ClojureScript and his talk focused on how they used it, how it helped them succeed, and some of its painful aspects. Specifically, he focused on the use of the D3 JavaScript data visualization library via ClojureScript interop.

In addition to a nice talk, he and his company put together a ClojureScript pamphlet that although a bit outdated at the moment2 is still a useful reference. Since his talk ClojureScript has matured thanks in no small part to his own efforts and comments.

Tune in next time

There are more Conj 2011 videos due for release soon, so I will try to keep up as they are released.


  1. I find myself studying many things by Jonathan Rees these days. 

  2. The cost of referencing alpha software. 

One Comment, Comment or Ping

  1. Radford Smith

    I see one major problem with using Clojure data over JSON for client-server communication: you lose interoperability. When you build your client on top of a JSON API, you can use that same interface for your public API. If you use Clojure data instead, you have to maintain a separate JSON version for the public.

    I’ve seen others go even further and abstract the server API into remote Clojure function calls, leaving the principles of REST behind. This might not be a problem for a small, isolated ClojureScript app, but for anything more you’re going to want to open up your data, even it’s just for yourself. For example, how would you make an iPhone app for your site if it only speaks Clojure?

    I wrote this comment with Steve Yegge’s rant from 2011 in mind:

    “The Golden Rule of Platforms, “Eat Your Own Dogfood”, can be rephrased as “Start with a Platform, and Then Use it for Everything.” You can’t just bolt it on later. Certainly not easily at any rate — ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it’ll be ten times as much work as just doing it correctly up front. You can’t cheat. You can’t have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.” [2]

    Everything I’ve read about this technique presents it as an upgrade rather than a trade-off. I see the benefits in using more powerful data structures, but the drawbacks seem even worse for medium to large applications.

    [1] Here’s an example from ClojureScript One: [2]

Reply to “Clojure Conj 2011 – Learning more pt.1”