Hang on. Your opinion is that Clojure isn't readable because you didn't find other Lisps readable when you were an undergraduate? But you haven't actually tried Clojure yourself?

I have tried Clojure, and my opinion is that it's easily the most readable programming language I've found.

Clojure has very strong opinions about complexity, which in Clojure parlance is a measurement of interconnectedness between components. The language is built around the idea of reducing complexity, about making things isolated and independent. Idiomatic Clojure code therefore tends to have a very flat structure consisting of isolated functions and data structures. It has a very high degree of code reuse, because it explicitly rejects encapsulation.

Clojure's syntax may be unusual, and individual forms are more information dense than many languages, however the structure of Clojure code is often much easier to understand, and for any non-trivial piece of code, that's the hardest part of comprehension.

When I come across a new Clojure library, I'll often find myself reading a bit of the docs, then heading into the source code to get an idea of how it operates. I rarely do this with an object orientated language, as OOP code tends to be deeper, more interconnected, and because of encapsulation, have more methods to understand. Java in particular is terrible for this.

Maybe Clojure feels odd for a few hours when coming from C-like syntax, but it becomes so obvious later on. I remember I felt terrified by the parens because I had not written anything serious in it.

I'd say the most natural pathways for Java programmers upgrading their language skills are:

* from Java, to Groovy, to Clojure

* from Java, to Groovy, to Scala

* from Java, direct to Clojure

* from Java, direct to Scala

Once someone reaches Clojure and Scala, they seem unwilling to give up what they've gained (the simplicity and macros of Clojure, or the higher-order typing of Scala) to switch to something else, even when that something offers more.

Syntax? Not seeing any syntax here.

Also LISP (I assume you are talking about Scheme or Common Lisp and not the 60s langauge) is not the same as Clojure. It does share some syntax and some ideas but its also very diffrent in many ways.

You might prefer your legacy java in the simple case, buts lets talk again when that java code has to do concurrency or other complex problems.

> Most of the modern functional languages read closer to the spoken word.

Its actually a absolut non-goal of clojure to 'read like the spoken word'. Its a goal of clojure to write code in a simple way, simple meaning a speration of concerns were each part is easy to reason about.

For single-instance applications, sure. But for scalable systems, 90% of your concurrency is handled by whatever message broker you're using anyway. Tasks, Async processing, Blokcing Queues etc etc - they're all handled by your JMS provider.

However often you find that its not enougth for you and then you will have to write some costume code yourself. You might think one message passing system is enougth but then its more and now you have to manage message from three subsystems in your application.

Ill use a langauge that makes things easy when things are easy and not very hard if they are hard.

Let's consider an example. One of the classic concurrency problems is managing a bank transfer. In this problem it's important that the debit and credit operations happen atomically. If one operation fails, then both operations should fail.

In Clojure, we'd write:

    (defn transfer [from to amount]
      (dosync
        (alter from - amount)
        (alter to + amount)))

A lot of the problems with dealing with concurrency are in communication between threads. BlockingQueues and Executors only deal with a small subset of concurrency problems, and blocked threads are a fairly inefficient use of resources compared to async solutions.

Why dont we ask Brian Goetz a Java Language Architect how "easy" it is, read his book [1] and then lets talk again how easy it is.

[1] http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...

I don't feel that there's anything particularly magical with the paren being on the left hand side of the verb that automatically makes it less readable than when it is on the right hand side of the verb.

Especially that alternating pairs business.

Having to know what is a macro and what is not affects understanding how arguments are evaluated, and basically everything is an argument differentiated only by position.

I've head one should read a lisp function not from the top town or outside in, but rather from the most indented part first, and then work your way up and out to discover the definitions.

The whole point of macros is that they are written in the same syntax as everything else (because of homoiconicity you can operate on your code as native data), you don't need to know what is a macro and what is not for 90% of the code you write. There are very little cases in Lisp languages in general where the difference between a macro and a function are evident, and in Clojure even less (compared to another dialect like, let's say, Common Lisp).

There are some times where that might be useful, but that's why we have a repl and macroexpand.

"that macro function is called and is passed the unevaluated operand forms. The return value of the macro is then evaluated in its place.

If the operator is not a special form or macro, the call is considered a function call. Both the operator and the operands (if any) are evaluated, from left to right." - http://clojure.org/evaluation

There are many macros and special forms in clojure where you have to understand that the arguments are not evaluated first - and if you try to reason about what happens as if they were eagerly evaluated you get the wrong answer or an error

That's why the pipeline operator (->>) is common. Then you just read it from up to down.

https://github.com/stuarthalloway/programming-clojure/blob/m...

https://github.com/tcltk/tcl/blob/master/generic/tclCompile....

Grabbed at random. I think the larger indentation and fewer parens do make a difference when you squint at things.

Of course, I also think as a professional programmer, if something does the job, get over it and get on with it. I use Erlang myself, which also gets lots of syntax complaints.

Just squinting at the code to see the shape of it rather than worrying about the contents, the C blocks look more distinct, to me.

C is more dispersive...

Thought I code way more clojure than C

But if I may, I believe treating inanimate objects as women puts them off more than LISP.