What is it about?

I got it wrong.


I thought Clojure was about being hosted and leveraging the power of host platforms such as the JVM and JS.

Not anymore.

Now it is about reaching everything. Interop with the GPU, Python, the unix shell, the Truffle languages of GraalVM and R demonstrates that it can be everywhere. The same basic principles of simplicity can be brought to any platform. On one of the conversations, @joinr called it "the ultimate glue language".


I thought it mainly was about persistent data structures.

Yes, but . .

With well-thought abstractions, one can also reach arrays of primitive datatypes inside and outside of the host platform, without losing simplicity and elegant grammar.


I thought it was about lightweight data modeling, as I learned from this post of Mark Engelberg – about having the power to do anything with JSON-like data structures, and using that to model everything.
It was about processing maps, maps of maps, sequences of maps, sequences of maps of maps, etc.
– a fun alternative to the popular way of thinking in tables, common to spreadsheets, relational databases and some programming communities.
I thought it was still a question, whether these two ways could be in harmony.

Not any longer.

tech.ml.dataset answers the question by bringing efficient table processing to Clojure. Also, as @cnuernber recently announced, it allows to seamlessly combine it with your beloved habits of working with sequences of maps, sequences of maps of maps, etc. This is may be the first time these two paradigms can live in such harmony that they are actually seen as the same thing.


I thought Clojure was about managing values and identities, and working with session state in a sensible way.

But it will be more than that.

Recent discussions with @generateme taught me that we can think beyond the single session, and use the same ideas of value and identity across sessions. Hopefully we will discuss that here further soon.


I thought it was about leveraging the power of the REPL, the text editor and s-expressions, combined in a way that practices the Lisp tradition of dynamic exploration.

But of course, these are also connecting to the visual world.

This is not new in the Clojurescript scene, where the REPL and the editor can be combined with a the browser in a live-reload experience.

What about backend Clojure?

There are some promising, actively developed libraries for data visualization and literate programming. This is not new either, as notebooks such as Gorilla REPL have been here for years.

What still remains to be figured out (I think) is how to tightly connect notebook interaction with a decent REPL and editor experience. But there are some ideas in that direction, suggesting how we can have both at the same time. More on that, soon.

On another direction, there are some neat ways to have visualizations inside your beloved REPL and editor, and they seem to be fun.


I thought it was about decomplecting problems and solutions into small, composable functions and libraries.

But it is more than that.

We are seeing beautiful examples where kind people reach out to work together and have tight collaboration across libraries, looking to build a coherent ecosystem.
See, for example, this discussion. Six library authors working on vega/vega-lite rendering are patiently mapping the tradeoffs across their solutions, seeking agreement on a common foundation.

As @teodorlu recently explained to me, even if lots of very different approaches coexist here, this community might be overcoming The Curse of Lisp.


The developments of the last few months made me realize that Clojure was not about what I had thought it was about.

In this short list, I tried to share some links to conversations that made that understanding sink, for me.


I’m trying to work on this direction with Chlorine for Atom (and Clover, for VSCode). I think very soon, I’ll merge this code: https://github.com/mauricioszabo/repl-tooling/blob/ae78fd6e6b5a0f97a71acd4dcc76da93aa8bc545/test/repl_tooling/editor_integration/interactive_test.cljs

What it means is that anyone can add “renderers” for evaluation results. What this means in practice is that you can, with a custom command, send a code to Clojure (or ClojureScript, or Clojerl, or Joker, or Babashka) and get back a result that renders as pure HTML. Even more, you can interact with these results: on clicking/hovering/any HTML handler, a command can be sent to Clojure and the result be reflected on the “renderer”.

It’s still on the very early stages, but I’ll already implement some integrations on it, so it can be battle-tested for real :slight_smile:


It would be a dull language if everyone had the same goal. I think the richness of Clojure is that users are so varied, with different interests, background and ofc personalities. It sounded bit “disappointing” until I read “but it is more than that”, which is exactly how I feel.

1 Like

First of all, brilliant post.

For me was always about syntax and DSL. Clojure is a useful lisp, and even though I haven’t write a single macro until now, I’m comfortable with the possibility to write. And besides that I can benefit with its existence because others create libs with great api.

I say DSL (Domain Specific Language) because Clojure facilitates to create the vocabularies and abstractions you want. It doesn’t try to limit devs in favor of a false protection as other languages do. This is why I don’t like strongly typed languages, professional devs should be able to choose to use types where it make sense, optionally as Clojure allow.

I say more about languages and abstractions in a post https://github.com/JpOnline/Blog/blob/master/language.md

1 Like