Simple-talk has an interview with Rich Hickey, author of the programming language Clojure (pronounced “closure”). Clojure is a dialect of Lisp designed to run on top of the Java Virtual Machine. The language is also being ported to the .NET framework as Clojure CLR.
Two things stood out to me in the interview: a comparison of Lisp with C++, and a discussion of complexity.
You’ll often hear a programmer argue that language X is better than language Y. To support their argument, they’ll say they wrote a program in Y, then wrote it in X in less time. For example, someone might argue that Ruby is better than Python because they were able to rewrite their website using Ruby in half the time it took to write the original Python version. Such arguments are weak because you can write anything faster the second time. The first implementation required analysis and design that the second implementation can reuse entirely or at least learn from.
Rich Hickey argues that he can develop programs in Lisp faster than in C++. He offers as support that he first wrote something in Lisp and then took three times longer to rewrite it in C++. This is just a personal anecdote, not a scientific study, but it carries more weight than the usual anecdote because he’s claiming the first language was more efficient than the second.
In his discussion of incidental complexity, complexity coming from ones tools rather than from the intrinsic complexity of the problem being solved, Hickey says
I think programmers have become inured to incidental complexity, in particular by confusing familiar or concise with simple. And when they encounter complexity, they consider it a challenge to overcome, rather than an obstacle to remove. Overcoming complexity isn’t work, it’s waste.
The phrase “confusing familiar or concise with simple” is insightful. I never appreciated the arguments about the complexity of C++ until I got a little distance from the language; C++ was so familiar I didn’t appreciate how complex it is until I had a break from writing it. Also, simple solutions are usually concise, but concise solutions may not be simple. I chuckle whenever I hear someone say a problem was simple to solve because they were able to solve it in one line — one long stream of entirely mysterious commands.
Thanks to Omar Gomez for pointing out the interview article.
3 thoughts on “Interview with Clojure author”
What was even *more* interesting about Rich’s CL / C++ rewrite claim is that he said he didn’t really know Lisp but was already very proficient with C++.
John, I’ve had the same experience with C++. Having done serious C programming throughout the 80s, I naturally adopted C++ for the 90s. Though I was comfortable with it, I must’ve sensed its complexity even back then, because I quickly found myself subsetting the language. Now I sort of dread looking at C++. I’d rather look at C.
C# provided a clean start and a new world, and it’s been the go-to language for me this past decade. But I’m afraid it’s suffering the same fate; they’re trying to jam everything into it now, and the language is no longer a breath of fresh air. If I were to step away from C# for a few years, I suspect I will view it, complexity-wise, the same way I now view C++.
After using Clojure for a few months and following the discussion related to its use and development, I continue to be impressed. Rich Hickey is an extremely insightful thinker and a good shepherd of further development of the language.
The community that has developed around the language is impressive as well — none of the snarky attitudes you often find among lispers, little of the fanboi responses you often see around other languages. Its genuinely thoughtful and helpful discussion.
And Lord, the language is pleasant to use. My experience with C++ is similar to what you cite. After using and teaching the language for several years, then switching to other languages like Java, Delphi, and even C, it was jarring to have to return to C++. After using Clojure, I find it almost as jarring to return to Java.
Things just keep getting better.