A few weeks of Clojure

4

For the last three weeks or so I’ve been doing virtually all of my development in Clojure building a couple small utilities for people. Prior to this I’d read parts of Stu’s Programming Clojure and written some trivial stuff in it before but I’m essentially learning the language as I go.

I have about 500 lines of Clojure code at this point (that’s just the sum of lines in the clj files so includes blank lines and comments). It’s ugly as heck, only lightly tested, and probably something I’ll laugh at a year from now, but it is does useful stuff and I’ve delivered it to our internal users.

500 lines doesn’t sound like a lot but Clojure is a concise language. I wrote a subset of this code in Java first (300 lines over 8 classes) and then ported it to Clojure (150 lines over 3 files). Given some refactoring time and more advanced Clojure usage, I suspect I could boil that way down to maybe another 2x. I can’t quantify it, but my general impression was that a higher percentage of the Clojure code was reusable on the second part of my project than it would have been in Java. My colleague also ported part of the same code to Scala but I haven’t had a chance to look at it yet.

It took me about 2 days to write the Java version and probably about 4 days to write the Clojure version but that was mostly due to learning Clojure while doing the port. As I got more comfortable I was really picking up speed in the last few days of last week.

When I work on a Java project, I find that when I’m working hard on something, it typically means I’m doing a lot of typing. I can see the solution and I’m finding the best way to render it in Java, which typically involves a fair amount of interfaces and other design pattern-y things. In many cases, my thought process is gated on how fast I can type. In Clojure, I find that when I’m working hard I spend a good percentage of time either sitting and thinking or trial and error in the REPL. As my Clojure improves that’s shifting away from the REPL and towards thinking. I’m never gated on how fast I can type but more typically on how well I am expressing the core of the idea at hand, which typically involves either a) thinking about data structures or b) thinking about processing over those data structures.

I find this switch to be wonderful. All of the cruft drops away and I’m focused on the core of the problem. I can see the beginnings of how to take the code I’ve written and really ratchet up the abstraction although I’m not quite experienced yet to make that happen or plan for it ahead of time. In Java, increasing your level of abstraction typically involves more stuff: more interfaces, more factories, more annotations, etc. A more abstract and powerful design in Java often actually increases the total size of the program. In Clojure (or any Lisp) the facilities available to create abstraction actually allow you to dramatically decrease the size of the program by creating your own language that maps more closely to the problem.

I have some other thoughts but I’ll save those for another experience report. So far, I’ve enjoyed my time with it and I’m going to continue pushing it. This week I’ve got someone new coming on board so I hope to do more pairing on Clojure and hopefully increase our learning velocity.

Comments

4 Responses to “A few weeks of Clojure”
  1. Buddy Casino says:

    I’m also experimenting with Clojure, and I find the philosophy more appealing than Scala.

    I’ve got that funny feeling that with Scala, the JVM finally has its C++ (Java being C).
    Am I the only one?

  2. Dave says:

    @Buddy: Probably; there’s no comparison between Java/Scala and C/C++ IMO.

    @OP: While I tend to agree, I’ve also found that with recent IDE’s I have to type *substantially* less than ever. For me the gating issue is reading comprehension speed: I hardly have to type at all, but I still have to *read* what I (didn’t) type.

    The cognitive overhead of reading Java is what kills me; not the typing.

  3. Dean Wampler says:

    There’s a curious thing about adding abstraction in functional vs. OO languages. In the latter, it seems we add more stuff and move “up”, as you say. In functional languages, it seems we move “down” towards relying more on the built-in collections and the standard operations like folding, mapping, etc.

  4. David Loeffler says:

    I first used Lisp in ’80 for describing integrated circuit layout from work Sussman and crew did on Scheme chip. Learned the language over the Internet then from friends like Bernie Greenberg and Richard Lamson at MIT. It was really great to write domain specific language macros and store layouts as Lisp code. Macsyma was another one of favorites. With macros the code read more like english. People complained about the ()’s but that was a lot better than all code you have to put in for type safety. But times changed and in order to make a living moved to Smalltalk then Java. Now have one giant one-man project to finish up and maybe I’ll have time to experiment some more.