It’s been a week, but I’m still revved up from attending Clojure/conj. The energy, dedication, and intelligence in the Clojure community all continue to impress me, and definitely influence my choice of Clojure as my preferred programming language. Of course the language itself remains the most significant factor, and that’s something I’ve been meaning to blog about for some time.
My language of choice has gone from C to Perl1 to Python to Ruby to Python again, and then finally to Clojure. Each transition has been motivated by a perceived increase in practical expressiveness – an ability to communicate both effect and intent more directly and efficiently, both to the computer and to other humans. C to Perl provided garbage collection, first-class collections, and CPAN. Perl to Python provided real objects, comprehensible semantics, and a syntax that did not resemble line-noise. Python to Ruby provided blocks, open classes, and pervasive metaprogramming.
Ruby back to Python takes a bit more explaining. In so many ways the languages are so similar as to be almost indistinguishable.
One difference is in the communities surrounding the languages. Ruby has come a long, long way from the days when most of its documentation was only available in Japanese. But – there are differing cultural norms between the two communities on how best to balance documentation, stable interfaces, implementation quality, and the introduction of new features. I feel that the Ruby community pervasively emphasizes the latter above the others to a greater extent than I prefer. The Python language, standard library, and third-party libraries tend to be better documented and more stable than their Ruby counterparts. Not universally or to an unjustifiable extent – just sufficiently that I see a distinction, and prefer Python.
The other most significant aspect is that I believe Python APIs tend to be more value-oriented than their equivalent Ruby APIs. This one is a little difficult to explain...
Ruby more closely follows the canonical OO model by having a concept of “messages.” All method invocations and function calls are actually deliveries of messages to objects. When you see a line of Ruby code like:
invoke_method arg
All you know is that the implicit self at that particular line is
going to receive the invoke_method message with the argument arg. You
first need to unwind the evaluation state to figure what object self
is at that point. Then you need to figure out how it will actually
handle the message, which may be via a class instance method, an
included module method, or method_missing. Messages themselves aren’t
first-class or introspectable, so there’s no way to ask “if I send the
invoke_method message here, who exactly will respond?”
Python in contrast has no implicit scopes and models everything in terms of attribute access and function-calling2. When you see a line of Python code like:
object.method(arg)
You know there is an in-scope, introspectable value named object at
this line. That value is asked via the attribute-access protocol for
its method member, which yields another introspectable value. That
attribute value is invoked via the function call protocol with the
argument arg. At every step of the way you have a concrete,
introspectable value backed by code you can find and follow.
In my experience these differences aren’t just a curiosity, but
directly impact the way one most concisely expresses code in the two
languages. In Ruby libraries it is a very common idiom to provide
methods invoked within a class definition or instance_eval’d block
which build state by modifying the implicit self. The moral analog of
this in Python (metaclasses) is relatively rare, and most Python
libraries provide interfaces in terms of concrete values. For a good
example of what I’m talking about, look at the difference between the
ruby-ffi and Python ctypes libraries.
And then finally, Clojure.
For the few years I’ve been using it, I’ve found that Clojure maximizes practical expressiveness in three ways which beat all other languages I’ve tried. It has everything you’d expect from a language like Python or Ruby, but then has adds these things on top.
First there’s the obvious: macros. Ruby and Python provide metaprogramming facilities which allow programmatically generating any constructs one could produce directly through code. But doing so is not always going to be as legible or compact as simply writing out the desired result, nor will it necessarily bear a clear relation to that directly-expressed version. With Clojure macros, you instead have the ability to do arbitrary in-code code-generation, using the same functions as for general-purpose code, and acting effectively like executable structural templates for the expanded code. In Clojure, there never needs to be any boilerplate – even if macros aren’t always the best method for eliminating code repetition, they are a method which can be used to eliminate any code repetition.
Second is the language’s functional style and culture. Without the language itself enforcing functional purity, the style of the Clojure standard library and the norms of the Clojure community encourage it. This gives what I see as the best of both worlds: the ability to write and reason about most code as pure functions operating on immutable values, while escaping to side effects and mutation when necessary without any excess ceremony. This makes it even more value-oriented that Python, with almost all execution happening in terms of values which are not only concrete and visible, but also immutable.
Third is Clojure’s definition as an explicitly hosted language, and specifically the JVM as the best-supported hosting platform. I was a bit resistant at first to getting deeply acquainted with the JVM and (oh, the humanity!) Java, but I now see it as a significant benefit. Part of practical expressiveness is not needing to write code incidental to the application domain. The vast ecosystem of Java libraries and the ease with which Leiningen allows access to them significantly cuts down on incidental code. The JVM itself of course is rock-solid, fast3, and universal. From a practical perspective, it’s a clear win for almost all applications.
Anyway, enough blogging – time to go write some Clojure!
1 In college >10 years ago, so cut me a little slack.
2 Which I believe you could think of as being messages, but I’m not sure that really helps much.
3 Well, after boot.