JUXT Blog

In a digital world where languages and technologies evolve at breakneck speed, it’s crucial to understand the foundations that continue to influence our tech choices. This presentation not only reveals how Clojure is deeply rooted in Common Lisp but also explores the grand vision of the JVM as a universal computing platform. It paints a vivid picture of how the tech landscape has transformed since the late ’90s, offering a compelling comparison between then and now. Additionally, it dives into the efficiency and performance disparities between Common Lisp and Clojure, providing valuable insights for developers navigating the complex realm of programming languages.

Now, let’s consider something we all hold dear – our planet and the technology we use. By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment. In a world where sustainability matters more than ever, our programming decisions can play a significant role. Join us in uncovering the enduring legacy of Common Lisp and its relevance in the ever-evolving modern tech world while making a conscious choice for a greener future.

You can find a summary of the presentation here: http://juxt.pro/embracing-common-lisp.pdf.

> but they could have been just as successful using another language. I remember reading about one founder that picked an obscure language because in doing so, it self-selected for more curious engineers who worked in the languages for fun rather than any other practical (re:job) reasons.

His thesis is that finding one really good engineer in said language was 1 in 10 (10 interviews to find 1 really good engineer) whereas in more commonly used languages like Java, JavaScript, etc., it might be 1 in 100

[Edit] https://www.juxt.pro/blog/clojure-in-griffin/

If we had picked Python, it’s very boring and reliable, and the same could be said of Java. But you’re picking the lowest common denominator. I would say high performers, and the best programmers are often people that will only work in niche languages. The problem is, there are good Java programmers, but there are also thousands of terrible Java programmers. If you pick the right niche, it’s easier to find the high-end talent. I think Paul Graham also made a very strong case that in a startup, you should be using the most powerful language you can, and that is Clojure. I interviewed with one YC startup that was using ReScript and ReasonML on the same principle (I asked the founder why he chose Reason).

I'd like that too (I trust SQLite more than almost anything), but it would prove difficult in some respects. Kubernetes intimately relies on etcd's watch capability. k3s does this with polling, which works fine, but some consideration would need to be given as to how to most effectively replicate that behaviour (eg. would LISTEN/NOTIFY work well on postgresql? I have no idea).

Further out, a case can be made that the whole business of reconciliation is one of event stream processing. My gut feeling for some time has been that the intersection of event stream and bitemporalism[1][2] makes a lot of the problems that motivate consensus protocols approximately moot. Done properly it might be possible to do away with the need for a master for a lot of things, which would improve scalability, failure tolerance and security.

[1] or Johnston's tritemporalism, I don't yet feel confident enough in my understanding to say.

[2] I am not alone and probably not the first to think so. For an example of a streaming-oriented bitemporal store, see Crux: https://juxt.pro/crux/index.html

> Don’t expect much more growth out of this language in terms of new projects written in clojure.

Why would an average dev not be able to maintain a clojure code base?
I'm going to guess what you really mean is a average dev that doesn't know clojure. In which case the argument your really making is that its hard to find "clojure devs". Which I think runs contrary to the numbers which suggest many more people wanting to work in clojure then can find jobs. This piece seems to echo that sentiment: https://juxt.pro/blog/posts/clojure-job-market.html

I think by and large companies probably struggle to find clojure devs in there immediate area. Which is why i see all the clojure jobs either

A) remote
B) in big cities

So its possible that companies could get great devs for less if they just allowed for remote.

Nothing backed up here by hard evidence, but worth considering that the language might not really be the only factor here.

> Read his other articles

Sure, let me have a look.

He wrote 8 similarly lengthy blog posts in just 2 months: https://www.juxt.pro/blog/from-specification-to-stress-test/ https://www.juxt.pro/blog/three-paradoxes/ https://www.juxt.pro/blog/what-outlasts-the-code/ https://www.juxt.pro/blog/composition-at-a-distance/ https://www.juxt.pro/blog/new-vocabulary-for-an-old-problem/ https://www.juxt.pro/blog/softwares-second-heroic-age/ https://www.juxt.pro/blog/capability-hyperinflation/

They contain a lot of classic LLMisms:

"Implementation is the shrinking currency. Not because it’s worthless, but because supply is exploding."

His past writing was much, much less wordy: https://henrygarner.com/

> Lest you think is just one weird corner of the sql spec, I found this helpful diagram explaining how the scoping rules work (from Neumann and Leis, 2023)

It's an excellent diagram, it really conveys the dissonance. Incidentally I interviewed Viktor Leis on a podcast last week about the paper where it's from: https://juxt.pro/blog/sane-query-languages-podcast/

A lot of people seem to believe that LLMs or other ML methods can overcome the complexity challenges of generating SQL accurately, but I'm yet to be convinced that a database-powered AI revolution can happen without somehow bypassing SQL.