Clojure 15th Anniversary: A Retrospective

2) Thats true, but its not leaky abstraction. Clojure never claims to abstract the host away, it embraces it so you can do all low level Java/JS stuff and seemlessly use their libraries without FFIs.

3) You have all Java/JS libs. Most Clojure libs are simply "done", so they get no commits. I don't know of any unmaintend ones.

4) Java is improving? Clojure is mostly done with that already. It was designed long after Java and makes many improvements obsolete.

Java is the standard for JVM. However, if Java was the perfect tool for any job, no other language would have been implemented over JVM.

I would rather use Kotlin than Java, who, to me, seems bloated and ancient. Also Java, the greater programming environment, kind of forces all things to be objects, unneeded inheritance, unneeded abstraction and patterns on top of patterns. I kind of like to use a more data oriented approach than object oriented approach, or pattern oriented approach, or Uncle Bob oriented approach. I strongly think that the shortest path is the best path, the less abstraction the better, the less CPU cycles used for something, the better.

Personally I really like that Clojure, Python, and browser targeting languages have less frameworky cultures.

As someone who codes professionally with Spring frameworks every day, this is a huge selling point for Clojure to me!

It is such a huge, opaque, convoluted, complex unpredictable mass of code, that forces broad changes to working code whenever you upgrade to a new major version.

One of my favorite Spring debugging anecdotes was where a coworker was trying to find a class from a runtime stack trace in the libraries. Only to discover that the class didn't exist in the source at all, but was dynamically generated by Spring at runtime!

Your other points I largely agree with.

In fact, I'd go as far as to argue that approach taken by frameworks like Rails and Django is an antipattern because it couples your frontend with the backend. This leads to all kinds of problems.

For example, it's much easier to horizontally scale your backend when you have stateless services. It's also much easier to add alternative frontends, such as mobile apps, since you already have a service API that can be resued. These are just two concrete examples.

2) Knowing the underlying platform helps, but you certainly don't need any deep knowledge of it. I've worked with excellent Clojure developers who only had superficial knowledge of Java or Js before.

3) I'd argue that Clojure actually does better in this regard than a lot of languages. There are orgs like Clojurists Together that actively fund development and maintenance of Clojure libraries https://www.clojuriststogether.org/ and Nubank themselves fund open source developers as well.

Another aspect is that many Clojure libraries are simply doing data transformations. The API accepts a data structure, and returns a different data structure as a result. Such libraries generally don't need a lot of maintenance work. I personally maintain a popular HTMLtemplating library called Selmer and a markdown parser. After the initial feature set was finished, there really hasn't been a lot of work that I've had to do on either library. I do an occasional update to add features, but these have been few and far between lately because these libraries are essentially complete.

4) The difference is that Java keeps growing as a language and that adds cognitive complexity. The bigger the language is the more things you have to keep in your head working with it, the more patterns you have to know, the more styles you end up seeing. All of this makes the language harder to use effectively, and creates room for errors.

The value of Clojure is that it's a small and focused language. It's stayed largely the same over the years, and people tend to use a common set of patterns working with it. I'd much rather have a small and expressive language than a large and complex one.

Furthermore, Clojure is completely different from Java semantically. It defaults to immutability, and it encourages much better patterns out of the box than Java. Personally, I don't think you can just keep bolting things onto Java to achieve parity with that.

And ditch Emacs (unless you are already using it/used to it) and try VSCode + Calva that runs basically out of the box.

Exceptions... yes.... they are clear when you know what they mean, but it takes time, because they are so long.

Startup... you only start a REPL once, so does not really matter (to me at least). For compiled code, you can try GraalVM, that has zero-ish startup time - because all static initialization is resolved at compile-time.

Just my $.02

Edit: Calva also includes a debugger - never used it, but here it is https://calva.io/debugger/

.Net code can be AOT compiled to native code. Doesn't JVM have a similar option?

2. It is. tools.deps

3. It's just one package to install? Why not use intellij or vs code if you want?

4. Yep. This is true.

5. I don't think I've ever thought that. Could you give an example?

6. Cider (emacs) and Calva (vs code) both have this.

7. You can do that just fine, once again tools.deps lets you do this with no hassle.

The best part is that you can develop it interactively via the REPL the same way as regular Clojure. You just run bb --nrepl-server and connect an editor to it. Calva with VS Code works great for this incidentally.

I haven’t written a ton of clojure but every large untyped code base I’ve seen is a mess, and usually there are people around it claiming it’s not

Also, due to the extensive use of FP and not much side effects, you can catch most of these mistakes at test time - not the same as a good static type system, but it is an interesting tradeoff, better expressivity, but not happening at compile time.

> compiler telling you if the pieces still fit together?

You still write tests in scala do you?

Open a REPL, and start working. You can just execute the code in realtime as you're refactoring. The size of the codebase is largely irrelevant.

Ironically, in Clojure the compiler _does_ tell you what is working and what isn't when you work this way :)

And anyway, you write tests don't you?

Besides that as others have mentioned: Clojure spec, various kind of automated testing, including, if that's your thing, generative-testing/property-based testing generated based on your specs (it's not always trivial but can really help at times).

You have to write many more tests and add a lot of predicates as pre/post conditions (invariants) to functions to check at runtime what a more modern compiler could have told you at compile time.

It adds a lot of friction and slows down the development process.

Combined with Clojure having lazy evaluation and nil punning it becomes frustrating in larger, domain heavy code bases.

Simple common “CRUD” line of business applications with shallow code paths and a database schema to serve as a secondary type system would probably suffer less from this, explaining why some devs say they don’t experience this.

For comparison, Typescript became so popular precisely because it mitigates similar problems for JavaScript once code based grew to non-trivial sizes.

What you point out is exactly what I think is the main drawback as Clojure (any dynamic language, really). It gets very tedious to waste so much time refactoring code and in the increased number of unit tests you need to write in order to avoid this from happening.

Personally, I think the lack of types in Clojure (and other dynamic languages) has another major drawback in that it doesn't allow you to easily express (and take advantage of) useful abstractions. In typed languages I got used to first write a "skeleton" of the application / library / module as a set of interfaces (traits, protocols, whatever expresses contracts in your language) and then develop and tests the implementations mainly independently. I find this extremely productive, in actual terms of amount of functionality per unit of time.

In Clojure I find myself doing diagrams or writing down data structures, etc. because there is no practical way of doing that in the language itself. Yes, I know protocols, types, spec, malli, etc. but they are not nearly as clean and useful (IDE help, etc) as let's say Typescript types.

I find this lack of expressiveness very frustrating, because I love Clojure otherwise. Persistent data structures are a game changer and the power you can get from a very small, generic API is mind blowing. And the data oriented paradigm, where everything tends to be expressed as data structures which are trivial to operate on, is simple conceptually and very powerful. I even got to like the syntax a lot. Once you get used to it, it's extremely clean, elegant and even clear (!).

Being as it is, though, I'm not sure that I would chose Clojure for a large project, even if I was the only one working on it. My brain needs typed languages as soon as I have more than 200 likes of code, it seems.

you're not supposed to do that in a dynamic language. Clojure's mentality towards data is "take what you need and ignore the rest", it's always the receiver of some data who is responsible to handle what they receive.

A lot of problems people have with dynamic languages would go away if they embraced the dynamism. If you're constantly refactoring because you make assumptions about the state of the program globally you're not actually utilizing the dynamic aspect of the language.

In practical terms, treat data in clojure the way you treat data over the web. When you get a some json data over a network you don't necessarily make absolute assumptions over its structure, you take what you need and deal with it when you receive it.

I see the fact that people often end up creating large and tightly coupled monolithic codebases in static languages as a negative aspect of static typing. Such codebases are difficult to reason about even if you have guarantees that the types align. Ultimately, you need to understand the relationships in code, and how they relate to business logic. The more coupling an application has the harder it becomes to reason about it as a whole.

Ideally, I think applications should be structured as a bunch of Lego blocks that can be composed together. Each component should encapsulate some functionality, and then the flow of the business logic should bubble up to the top and expressed in how these components are chained together.

Even if your assumption is true, what's wrong with that? A language which offers more value over an existing base of knowledge is valuable and isn't uncommon.

Clojure, the product (largely) of one person, is more opinionated than CL, the product of a committee. As a result, I find its design to be more cohesive, being oriented around functional programming and a set of core abstractions which play very well together. It has a bit more syntax than CL does out of the box, mostly for collection types.

But the biggest practical difference for many people, once they get their heads around Clojure's functional nature, is Java interop and the JVM. It is idiomatic to use Java classes directly from Clojure, and the library ecosystem is just vast, dwarfing any other lisp's. Deployment as an uberjar is typically a smooth story.

These days I'll reach for Common Lisp for personal projects, simply because of its startup speed and because I like some of the quirks of the language. But if I am going to need a library I know exists in Clojure/Java and is solid, which does happen, Clojure's a no-brainer for me.

Finally, there are a lot more jobs for Clojure than for CL, as far as I can tell.