An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Clojure/conj 2013 - a quick recap

November 18, 2013 ·

This was my third Clojure/conj and the first year it's been outside of Raleigh, NC - with the actual event at the George Washington Masonic Memorial, in a beautiful theater, and lodging at the (expensive) Embassy Suites, just a few minutes away. As usual, the caliber of the talks was (mostly) excellent - which is important in a single track conference - and the hallway / bar conversations were also very educational / entertaining!

I'm not going to go over the talks one by one - I think Logan Linn has a great post about the Clojure/conj 2013 talks - so I'm just going to mention some highlights:

Russ Olsen's "To The Moon!" was an inspirational closer for the conference: go home and do something hard! Tim Ewald's "Clojure: Programming with Hand Tools" was a brilliantly illustrated metaphor for the benefits of simplicity, as enshrined in Clojure's approach to both language design and problem solving. Aria Haghighi's "Prismatic's Schema..." covered a practical tool for both data validation and documentation that really caught my fancy - more below. Mike Anderson's "Enter the Matrix" really showed the power of protocols and clean, simple design, allowing for a high-performance matrix manipulation library (core.matrix) with swappable implementations. Timothy Baldridge's "core.async" cut straight to the chase with an entirely code-based presentation illuminating many of this cool library's features.

Honorable mentions also go to: Jennifer Smith for her "Internet of Strings" talk which showed how a contract DSL evolved that helped her specify and test interactions with third party systems; and Doug Selph's "Personalized Medicine, Powered by Clojure" which told the story of Clojure creeping into the corners of an organization and ultimately replacing Ruby on Rails for a core system!

Prismatic's Schema caught my attention so strongly that I actually skipped several day two talks in order to experiment with it in a real world code setting. I'd previously experimented with core.typed (a.k.a. Typed Clojure) as a way of adding type-based testing to our current automated tests at World Singles. I really like the premise of Typed Clojure but, right now, it's a little rough to use: you have to annotate everything in a namespace, or else add code to explicitly only warn for the unannotated Vars (and then ignore all the warnings in the output), you have to add annotations for called functions that core.typed doesn't know about, there's no type inference yet, the actual types are a little unforgiving sometimes (especially around number handling). It's an amazing project - even in my short time trying it out on production code it found a logical error very quickly - and I like that it can be applied entirely externally to the code. Right now tho', Schema provides a more optional approach: you can annotate just what you want, you can add explicit validations in your test suite, and overall it feels less formal and more pragmatic. That said, Schema isn't Typed Clojure - it doesn't analyze your code and it only provides runtime checks so your tests have to exercise enough paths to allow Schema to actually do its job. For now, for us, Schema provides enough additional checks in our test suite, without a huge amount of work - and it allows us to add type-checking where we feel we need it most. If Typed Clojure gets type inference and can be a little more optional, I can see us switching entirely to that. It all just shows what an exciting community we have with Clojure.

Tags: clojure

2 responses

  • 1 jmh // Dec 3, 2013 at 7:24 AM

    Typed clojure sounds horrible. I do have an open mind, however. Could you elaborate at some point on the real world benefits since some of us are trying to extricate ourselves from B+D typed java and just avoided jumping into scala over fear of type system complecting. Thanks.
  • 2 Sean Corfield // Jan 11, 2014 at 11:05 AM

    Since posting this I've dropped Schema and gone back to core.typed again. Since Schema is purely runtime, I didn't find it added enough above and beyond our existing tests. Probably our data structures just aren't complex enough to warrant it (except maybe around our search engine integration). Core.typed on the other hand can check types statically and find bugs or verify your code without running it - including identifying where nil can escape. I'll blog more about out approach to core.typed now that we've figured out a good rhythm for using it.