Well, you're always at the mercy of whoever wrote the code, but I will just say that in my experience (as an intermediate Clojure developer, I learned it in 2018 and have been doing it professionally ever since) reading other people's Clojure code is quite easy, since basically every line of code builds on the same core abstractions (mainly the seq abstraction) and uses the same handful of functions from Clojure core (the standard library). And obviously it's mostly pure functions and immutable data, so you get the benefit of being able to isolate the code and test it out in the REPL.

The main advantage of Clojure's particular data-oriented style is that there are no classes and associated methods to learn. Clojure basically defaults to using data literals for pretty much everything and the same custom is respected by most of the popular libraries (even many of the Java and JS wrappers). That's also part of why the code is pretty simple to read and why you tend to use the same few functions and macros for absolutely everything you do: you're literally just manipulating the same few kinds of data structures all the time.

Officially, by the book, you're supposed to use data access functions to give everything distinguishable names and keep it clean. What I ran into is that some nice language features for writing code quickly and tersely, such as map destructuring, actively discourage you from doing that. And without that, the difference between a map full of data and a class is that a class has a single file you can read to find out what's in it, while a map may have been built up in a completely ad-hoc manner.

I think the code maintenance story may have actually been a little bit better back when I was using lisp, because lists. It's actively painful to use raw functions like cdadr to unpack your data structures. Whereas assoc-in is a fun toy and encapsulating it so you don't get to use it as much would be a bummer.

From Rich Hickey's "History of Clojure"[1]:

Not all is rosy. Users perennially report dissatisfaction with the error reporting from the compiler and various macros. They are confused by Java’s stack traces. They face challenges maintaining and understanding, e.g., the data requirements of a codebase when a discipline around documentation has not been maintained.

Hickey is signaling here that "commenting discipline" is a must for working with Clojure.

[1] https://download.clojure.org/papers/clojure-hopl-iv-final.pd...

The issues I've had with Clojure are the small community leading to questionable documentation and supporting libraries just feel a little underdone once off the beaten track. There is also the radically different style of programming (which is also the biggest plus). But the power of the abstractions isn't a problem, it just means there is less to read. If anything, reading the source code of libraries becomes more feasible because often libraries are about instantiating an idea than writing lots of code.

Well, depends. For example, reading my older Haskell code is definitely harder than my Java code. Also, only a handful of teams is lucky enough to have only good programmers. There is always someone who sees some great advanced concept and applies it without the necessary know-how on the dangers/context of that feature. I think Haskell, Clojure and Scala as well are somewhat prone to this.

In my own day-to-day work, I see this issue with Scala programmers (myself included) who suffer from a tendency to see any kind of struggle with code as a valuable learning process. All of us got to where we are, slinging around monads in a "hard" language, because we have an appetite to expand our mental repertoire and a tendency to lean into difficulty. Selectively applied, this is a wonderful attitude to have towards learning programming. It is a counterproductive attitude to have towards your own codebase, though. In your own codebase, you have to flip your assumptions on their head and assume that if code is difficult to read, then more work should have been put into writing it.

I understand your concern, if you're used to old-style PHP or Perl, which many people say is "write-only", because it's incredibly fast to create code, but a nightmare to maintain it.

That said, I think Clojure is a bit difference, since the entirety of the language is designed to make it easier to actually make abstractions. It's trivial to break things into smaller functions and compose them, it's easier to compose stream-based computations, and it's even not too hard to do a fairly compositional concurrent system once you've gotten used to core.async.

Very often when I write Clojure, I do a "quick and dirty" version of whatever I'm trying to do (giant functions, everything in one file, single-letter variable names, etc), just to get something working, and yet I still find it fairly straightforward to read, and also fairly straightforward to make non-gross later when I have more time. Most of the time refactoring really is as simple as "cut and paste".

EDIT, Cont'd:

There are definitely exceptions to this. Occasionally people new to the language will find out about macros and try and build a bunch of custom constructs that are incredibly hard to debug. There's definitely an art to figuring out the best time to use a macro (one that I still haven't mastered, if I'm being honest), because abusing that feature definitely can lead to problems of maintainability.