A Lesson and Concern from Clojure’s Achievements

Having listened to Rich Hickey’s great ideations together with Markus’ helpful articulation has made it possible for me to understand why and how Clojure is needed. Perhaps this sense of certain enlightenment boils down to my inexperience and ignorance in the area, of which I am still learning from. Still, I feel like I have learnt quite a lot. Thus, I have a deep appreciation for this particular episode, and for sure I will listen to it later on in my career to refine all these concepts, ideas, and explanations.

Outside the realm of discussed technicalities, a lesson that will last with me from this episode is the importance of community involvement and design. In contrast to Lisp, Clojure has clearly been designed for mainstream use. While it holds to its core an idea of simple syntaxes and semantics, it is not dogmatic. Yes, it favors immutable values, but, if you need to, you can use referential types for asynchronization and/or mutability. Even better, you can write macros, which essentially adds blending features to the language instead of building atop in layers of APIs and libraries; or at least it does not look that way given its remarkable idiomatic simplicity. So, learning from Lisp’s shortcomings, albeit justified for its times, Clojure is general-purpose as in you can use the language to write anything computational, and hence everyone can speak it.

The previous point is better demonstrated in its interoperability with Java. Nonetheless, I have my reservations with this one, which is why this observation is isolated in its own paragraph. Indeed, what a better way to invite possibilities into the language than making it possible to use everything built on Java! Yay and nay, I think. My worries are, mainly, that Java and Clojure are, not surprisingly, written in vastly different manners. For instance, in Java it is common practice to write in Camel Case, while, as far as I have read from respective snippets of code, in Clojure you abbreviate words and append dashes to coin variable names, maybe in an attempt to simplify the language even more in the domain of specifications. Furthermore, Java needs the dot operator to call methods from classes, which in Clojure is used like any other function akin to + or defn. To me at least, Java interoperability in Clojure feels not quite right. It is harder to get around, write, and read. And yet, my biggest concern is the lack of native tools and libraries, for these are already accessible under the JVM. As an example, once I searched for UI libraries for Clojure. Lo and behold, in my search I could not find any obvious one, reading suggestions to instead make use of Java’s Swing. If I wanted to use Swing, I would use Java, not Clojure, so as to not confuse myself in trying to wrap my head around getting the former language to work in the latter, and even not to confuse myself once documented and archived. Like attempting to “mix” any natural language, say Spanish words and pronunciations with English syntaxes, this out of all is the most unpolished and worrying feature.

Ultimately, Clojure’s greatest achievement is its great openness. We all appreciate that. But perhaps there is a limit to how much openness gets to define ourselves. This isn’t to say we should repress any diversity; that would be a fatal mistake. It seems to me that Clojure, in its honorable and well-intentioned quest to blend identity and state, forgot its own. For what use, then, is a language, an entity, that is defined entirely by others, be it accidentally or intentionally.

Clojure is cool. I quite like it. But this is the lesson I get out of it, and my humble concerns.

Or maybe I am just ignorant; that is also a possibility.

 

Voelter, M. (Host). (2010, March 22). Rich Hickey on Clojure (No. 158). [Audio podcast episode]. In Software Engineering Radio, IEEE Software. http://www.se-radio.net/2010/03/episode-158-rich-hickey-on-clojure/