I find it interesting he includes Mozart/Oz (CTM). It'd be great to see more ideas from that language coming to Clojure.
Also Norvig's AIMA. Clojure could be well positioned for neuro-symbolic AI. That's somehow connected to Anglican, discussed in the History of Clojure article.
Funny that it includes Instructor's Manual for SICP but not SICP itself. I wonder if anyone has read it (the manual), is it good? Seems it is not available online.
I think it's suitable for people who are trying to work through SICP by themselves, it contains some discussions and extra exercises that could be helpful in that scenario. Otherwise I think it's just like a small addition and won't vastly shape your experience with SICP, the main content is in the main book :)
This book was written before Clojure was released as 1.0. (1.0 and Programming Clojure were released together!) Stu and Rich worked closely at that point. The process of writing the book and Stu were influential on Clojure.
Has Anglican been used in any significant project?
It looks interesting (though tbh I barely understand what it does.. it's borderline technobable to me) but I haven't been able to find it used anywhere on Github. It's also gotten zero updates since 2018
Doesn't mean it's not a hidden gem... I would have said something similar about Missionary as well
I’m seeing a lot about clojure language, especially recently. I’m missing an insight into the clojure community, especially in the context of libraries and job market.
E.g. I’m not aware of any large framework like Rails or Phoenix. Is this something that is missing and yet-to-come, or there is no need for that?
How does this affect job search, are Clojure jobs less about SAAS/CRUD apps? Does each place build their own custom tooling?
There is no dominant over-arching framework like in some other languages. There are many smaller ones, with different approaches, so there is more choice.
As for SaaS apps, Clojure is a really good fit, because of ClojureScript. You can have a large part of your code as .cljc files, and compile both to JVM and to JavaScript in the browser. I found this is an incredible advantage, enabling a single founder like me to write and maintain a complex SaaS.
I don't know Blazor, and it's difficult to tell from the webpage.
But I can tell you that most of my model (business logic) code is written in Clojure and compiles to both JVM and ClojureScript. In other words, I use the same code on the server and on the client. I also use EDN (meaning Clojure) as the serialization format between them, so I avoid serializing to something non-native. All this buys a lot of incremental improvement.
ClojureScript gets compiled using Google Closure compiler in "advanced" compilation mode — for those who might not know, this is not a "minifier", it's a whole-program transformer which does renaming and dead code elimination. The result is highly optimized JavaScript. I guess that's why there isn't much excitement about WebAssembly in Clojure circles — the current state of affairs is really good enough. In my experience (complex SaaS app), DOM operations are a performance bottleneck, not ClojureScript.
I worked with Clojure professionally, and one of the things it forced me to unlearn was reliance on frameworks and lots of little libraries for everything. It's just not necessary when your language is so expressive and simple.
I know nobody believes me when I say this, but I really mean it.
Clojure users tend to prefer tiny libraries that excel at one task and compose them together. While Pedestal is definitely a framework, its eclipsed by the sheer popularity of Ring (HTTP abstraction library similar to Rack), where you roll with your own choice of web server, router, middleware, database, data validation and coercion, etc.
Right. Instead of 4 frameworks competing, yet having mostly similar say 25 underlying functions, clojure has say 50 functions (assuming half the framework code overlaps between frameworks) as libraries that can be composed to achieve the same functionality as those frameworks, and more.
The Clojure's approach is to favour libraries over frameworks.
We use Clojure on various style of applications (mainly web and API based), hosted on widespread infrastructure technologies of Cloud Providers (Kubernetes, PostgreSQL, Kafka, etc.) and it's a breeze: here are our reasons for choosing Clojure https://defsquare.com/blog/why-we-bet-on-clojure
If you want to look at libraries where some people have settled, here are our _opinionated_ takes on libraries that we use on almost every project:
For infrastructure stuff (PostgreSQL, Keycloak, Solr, Kafka, etc.), just wrapping the underlying Java library or driver is often enough, and there are lots of wrappers for easing the integration. And we implement Hexagonal architecture style to put all of that in place.
Don't be afraid a libraries not moving a lot recently, it's a sign that the library is mature and battle-tested.
Clojure is a joy to use every day :)
Yes I agree, timbre and clojure.spec are great and I used them a lot, nowadays I move to μ/log and Malli for instance. My comment was to provide some guidance for someone outside of the Clojure community to navigate in the library ecosystem.
I updated my comment to reflect that it's an opinionated take and just that.
I think Clojure had a moment 2015 to 2020ish, but it's passed. People still use it, even though it sucks. What's not to love:
- Incredibly slow
- Hosted on the JVM, so you're going to be dealing with Java eventually
- No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code
Huh? Clojure is one of the fastest dynamic languages. It's not intended to replace C++ or Rust.
> - Hosted on the JVM, so you're going to be dealing with Java eventually
In the real world this is a blessing since there are a lot of useful Java libraries out there.
> - No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code
How did you come to this conclusion? Lack of automatic TCO doesn't mean you have to write macros, and most people in the Clojure community will tell you to prefer functions over macros unless it's absolutely necessary.
Almost as fast as Java, and for performance critic processes 99.9% of the time we bump on infrastructure performance problem BEFORE hitting the wall with Clojure (see https://clojure-goes-fast.com/blog/ for tips and tooling about performance)
> - Hosted on the JVM, so you're going to be dealing with Java eventually
For me it's a major selling point: JVM is battle tested and a wonder of engineering.
The Java ecosystem richness is incredible (see tooling above for monitoring and profiling for an example). And the platform is constantly moving forward (see latest JDK with virtual threads, generational ZGC, etc.). And of course GraalVM... (https://www.graalvm.org)
> - No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code
Never have been a problem and I don't see the point with macros, and code we write looks _very_ functional...
> JVM is battle tested and a wonder of engineering. The Java ecosystem richness is incredible (see tooling above for monitoring and profiling for an example).
This is all true.
That said, the way I can't help but feel is: keep that entire galaxy of insane bloat two and a half million miles away from me please. :p
It's definitely not over. I got into it professionally in 2018, and have remained employed with it at three different companies. There's turmoil around it because startups use it with great success, but then as they want to scale they have a hard time finding enough devs to throw at their new ideas.
However, I want to point out that sometimes Java can peak its head out. If you rely on Java tooling you will also likely need to have some idea of how Clojure implements things in Java.
So while Java gives us access to a great variety of tools and libraries, heavy reliance on the host can make things a bit more difficult, especially for new programmers.
Thought I'd seen everything from Rich but I somehow missed this. Thanks for sharing! I enjoyed the insight into his process rather than just the fully formed idea.
Easier to browse list: https://www.goodreads.com/list/show/137472.Rich_Hickey_s_Clo...
I find it interesting he includes Mozart/Oz (CTM). It'd be great to see more ideas from that language coming to Clojure.
Also Norvig's AIMA. Clojure could be well positioned for neuro-symbolic AI. That's somehow connected to Anglican, discussed in the History of Clojure article.