(take 5 colin-jones)

Posted by on May 22, 2012

Colin Jones is a software craftsman at 8th Light and Clojure veteran. His contributions to the Clojure ecosystem are far and wide, but tend toward helping newcomers to discover the language and provide tools for getting started as quickly as possible. In this installment of the (take ...) series Colin discusses koans, TDD, REPL-ing, and the Clojure Conj.

What are koans in the context of programming?

The basic idea is that they're exercises to help you learn a particular language or other technology. There's a Zen metaphor that ties things together, but the main thing is to have small, bite-sized chunks to guide folks in their learning without being overwhelming. I first heard about the idea in the EdgeCase Ruby Koans, and they in turn credit other sources (including The Little Lisper! with inspiration. So when Aaron Bedra started the Functional Koans project, I was excited to pitch in, and before I knew it, we had a bunch of people having fun working through the Clojure Koans, as their first exposure to Clojure.

Is there a place for TDD in the Clojure ecosystem?

Of course! I think Brian Marick has shown that most publicly with his library Midje, and related screencasts and conference talks, but there are a ton of other great testing tools out there as well: Speclj by my boss, Micah Martin, LazyTest, Expectations, clojure.test, etc.

I have heard TDD and deep thinking put into stark contrast with each other at times, but the people I respect in the TDD world certainly do a lot of deep thinking about simple design, so I think we sometimes get a bit of a false dichotomy.

I personally find a lot of benefits to unit testing - it's a way of making my thinking about problems concrete, and when I'm done, there's an automated system looking for assumptions that have become untrue.

What itch are you attempting to scratch with your latest project REPL-y?

OK, the 5-second version is that I want it to be easier to use a Clojure REPL, unix-style, at the shell. Projects like Russ Olsen's dejour were working towards similar goals, which I found exciting, so I got in touch with Russ to pitch in. As it happened, a lot of my ideas for improvement could be implemented orthogonally to dejour: handling Ctrl-C interruptions without bailing out of the process, basic code completion, in-REPL examples (via clojuredocs), and a truer readline-like interface (because let's face it: JLine 0.9.94 is broken). Hence REPL-y was born.

Down the line a bit, with some encouragement and help from Phil Hagelberg and the Leiningen team, it's now the default REPL frontend for the upcoming Leiningen 2, which is now in preview (nREPL is the backend). So at this point, REPL-y is wiring up of a bunch of great projects: Clojure, JLine2, clojure-complete, nREPL, and clojuredocs-client. There's a shell script to run REPL-y alone, but of course I expect the version in Leiningen to see a lot more use.

The project lives at https://github.com/trptcolin/reply (varying pronunciations are both acceptable and hilarious).

How can Clojure improve, in general?

Language-wise, I don't have too much to say. I know a lot of folks struggle with the various ways of pulling code in from other namespaces, so maybe there are ways to make those easier to use. My main interests have mostly been in helping people get over hurdles - which is of course a cause shared by a lot of people on the IRC channel and beyond. So, needless to say, I was very impressed by the fact that the planning for Clojure 1.4 included error messages, documentation, even potentially a command-line launcher app.

Tools-wise, I think things are moving in the right direction. Of course I mentioned the REPL stuff and Leiningen, and there are dozens of great new things coming out all the time.

I'd love to see clojure.org become a bit friendlier as an introduction to Clojure, from the very first steps. I wonder if it'd be possible to have something like the Java Tutorials that's maintained in an "official" way? There's so much incredibly good information on clojure.org - I refer to it often - but it can be intimidating, and things get out of date from time to time. I also think function findability can be hard in the clojure.core namespace from a REPL if you don't know what you're looking for, like if you want an operation on a particular data structure but don't remember the function name, so maybe a similar function to find-doc could do some nice grouping, like what's laid out on http://clojure.org/data_structures.

First impressions matter, and if we can hook people right at the start without compromising our principles, I think that's a really big win for the language and the community.

You've been to both Clojure conferences; was this years' offering different than the first?

I was pretty bummed about the lack of Clojure temporary tattoos this year, but you can't win them all.

Seriously, though, this conference is amazing. Certainly there were differences: last year's seemed a bit more language-focused, and this year's seemed more product- and library- focused. That's a pretty broad and unscientific impression, but suffice to say, both were awesome.

Some of the bonuses this year: an additional day of talks, bunches of informal sessions that sprung up in the conference space, and lots of great restaurants within walking distance. The talks, like last year, were fantastic. I suspect we'll see even more of these great stories about the things people are building as Clojure gets used in production more and more.

Plus, Overtone? Bad ass.

blog comments powered by Disqus