A History of Clojure by Rich Hickey… enjoy!
Seventy pages! I have something to put on the reMarkable tonight
When I first was learning Common Lisp I was appalled at the tolerance on Usenet comp.lang.lisp of arrogance, hostility, intimidation and other anti-social behavior of the presumed ‘smartest guys in the room’. I was determined (a) that the Clojure community would not be hosted there and (b) that kind of behavior would not be tolerated.
A thrilling read!
And more than a passing resemblance to some of his motivational talks.
Might even be an effective lure for people who’re on the fence about learning Clojure properly, because it introduces the concepts by-the-way in an adventure story!
Although, when the movie version comes out, there are one or two more things I’d like his memories of.
It was a great read, and I found I didn’t realize how much time has already passed since I first tried Clojure, and how many things were added over the years.
I found it interesting that Rich emphasized transducers as an essential feature that we would have rather had from the start. I find transducers to be an extremely useful building block and I think they are under-appreciated and misclassified as an “optimization feature”.
I don’t know how Rich finds the time, I struggle to keep up to date with my netflix shame shows.
Clear, thoughtful, engaging, I enjoyed reading it very much.
Really good read. I feel like this could be a way to at least make coworkers consider Clojure, but the length is maybe a little much for someone not already into language design or Clojure.
Yes, a great read. Especially for a more comprehensive view of the motivations and challenges of making Clojure happen.
what a treat!!!
my first thought was… this does not read like a paper at all… IN A GOOD WAY!!!
some of the highlights… in my opinion…
I started working on Clojure in 2005, during a sabbatical I funded out of retirement savings. The purpose of the sabbatical was to give myself the opportunity to work on whatever I found interesting, without regard to outcome, commercial viability or the opinions of others.
In December 2009, having stretched my self-funding for almost 4 years and depleted my retirement savings, I conducted a funding drive to continue development for 2010.
Clojure is full of the great ideas of others, but I alone take responsibility for its faults.
Information system programmers have the thankless task of attempting to superimpose somewhat regular models over information and real-world activity that refuses to comply.
I had always been a language geek, playing with Lisp, Prolog and Smalltalk in my spare time.
I took this as an agenda item for its design but not as motivation to seek their input in advance, because at the time the advice from professional developers about Lisp was “it’s dead” and about functional programming was “what’s that?”, and about writing a new programming language was “you’re crazy”.
Prior to embarking on Clojure in 2005, I had made several attempts to create a bridge between the JVM and Common Lisp, in order to increase the latter’s practicality and acceptability. These were DotLisp [Hickey 2003], an interpreted Lisp with host interop for the CLR, jFli [Hickey 2004], a library that embedded a JVM in CL, and Foil [Hickey and Thorsen 2005], a library that exposed a similar API but used IPC between the CL runtime and the JVM. None of these yielded productionlevel solutions, but they definitely informed Clojure’s ultimate host syntax and fed the idea of Clojure being hosted.
At some point I had my “I’m mad as hell and I’m not going to take this anymore!” moment, in my backyard, on my hammock.
As character-building as that was, it need not be so today.
My brother, Tom Hickey, designed the Clojure logo. The Google group mailing list approached and crossed 100 users and I joked with my wife that I might eventually get to 500 users, to which she replied “don’t get your hopes up”.
My wife Stephanie supported my sabbatical, extended unemployment, career sidetrack and extensive travel, and listened for many, many hours to my ravings about persistent data structures, STM and other technical minutiae. Thanks Steph!
all in all i think this account paints a well balanced portrait of clojure’s evolution… keeping things in PERSPECTIVE… also… this kind of reminds me of something i’ve seen in what has to be the funniest clj talk ever:
what i have in mind happens at 26:35
…hmmm… anyway… so… since i have now highlighted so many of the positive aspects… perhaps i can also point out a tiny! tiny!!! fly in the ointment… for me… well… i would have loved to get a paragraph mentioning / discussing emacs… since… well… since i LOVE!!! emacs … and therefore i am always very pleased when i hear / see people talking about it ( p.s. if you found this paper interesting to read… you may also enjoy: https://www.gnu.org/gnu/rms-lisp.en.html )
p.p.s. turns out i gave you the wrong link!.. i actually wanted to point your attention to:
( but the 2002 talk is fine too… so no harm done )
p.p.p.s. other than the great clj paper i have commented on a bit…
Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 71. Publication date: June 2020
there is also:
Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 74. Publication date: June 2020.
This was very enjoyable and the part about transducers in particular was great - a simple explanation of something that was originally hard for a lot of people (myself included) to understand.
I’m curious about Rich’s regrets regarding not having transducers and protocols earlier on. Has this been discussed at length on a public forum before? I’d like to know what the benefits would be of that change. Would it be a simpler implementation? Better performance? Both? I’m also wondering whether it would be a breaking change to make that change now, or if it’s just a big undertaking an there are more important things to work on.
that is a great question about how would transducers look differently if it was designed in originally. Or does he mean, developers would be more apt to use them more often if they were there early on?
They don’t seem particularly difficult to use or create, but I don’t observe they being used sometimes where they could be used.
Regarding protocols, I believe this is the main thing. Since clojure can be implemented in terms of protocols instead of interfaces, it would be one less thing to tie to the host language.
It’s not quite directly addressed, but Rich does talk about it in the clojurescript language release announcement. Clojurescript IS implemented in terms of protocols. I believe his initial mention of protocols is at the linked time, ~11 mins in but I think he might come back to it later (I listened to this a few weeks ago).
The whole thing is probably worth a (re)listen if you’re interested Rich’s thoughts on a fresh implementation of clojure a few years after clojure. (Of course with the major differences and tradeoffs involved in cljs).
Not speaking for Rich, but I have spent a lot of time in the guts of Clojure. Clojure is primarily defined in terms of Java interfaces, which limits extensibility in some ways whereas implementing those things in terms of protocols would have allowed a lot more of Clojure to be implemented in Clojure and be more extensible. And ClojureScript is a good example of that. Changing that in Clojure is really not feasible at this point - it would break too much stuff, both internally and external users of the Clojure interfaces.
Transducers are a fundamentally simpler model (specifically in that it separates iteration / transformation / aggregation) and shows that you can recast most collection transformations into reduction, and thus could be more central to Clojure than the sequence model (which is still also useful for dealing with infinite and lazy use cases). If that tool had existed earlier, I imagine there would have been many different design choices along the way. Certainly reducers would have been different, although they were really a stepping stone to developing transducers.
Anybody know if there is an HTML-version or some other mobile friendly version available of the PDF?
The paper mentions at the very beginning this lady:
Shepherd: Mira Mezini, Technische Universität Darmstadt, Germany
I find it interesting, because I currently work in Darmstadt, which is a small university town very near to Frankfurt. Is the lady somehow active in Clojure community? Or in what way was she a “shepherd” of that paper?
Googling shows she is rather accomplished and renown computer scientist in the field of researching computer languages and cloud environment
The role of a shepherd (when it exists) in academic conferences is to help the authors improve the quality of their paper (integrating feedback from reviewers, etc; in some cases they are assigned only to “borderline acceptable” papers, though I doubt this was the case for Rich’s paper), they are not necessarily experts in the specific topic of the paper (though they are typically experts in the area)
I believe all of the papers in HOPL had shepherds because they are pretty long papers written over a couple years with multiple editing passes.
Regardless of her specific Clojure experience, it would probably be worth contacting Mira Mezini to see if there’s a chance to learn something from her. (I say this because I have had great experiences reaching out to professors about their research over the years.)
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.