A quick analysis of the article from the point of view of an ordinary Clojure programmer: 1) Yes, it's tied to the JVM (or JS). This is a huge trade-off and no

A quick analysis of the article from the point of view of an ordinary Clojure programmer: 1) Yes, it's tied to the JVM (or JS). This is a huge trade-off and not without its costs, but it's one Clojure programmers are happy to make. 2) You can't do reader macros: true, Rich Hickey dislikes them because of the nasty effects they have on re-use. However, Clojure now has reader literals which fill in _some_ of this gap. Again, a trade-off. 3) He doesn't like [] and {}. I don't really understand why: paredit copes perfectly well with them. I never actually need to parse ))]))}) in my head. 4) Over-reliance on recursion. Possibly true, but a decent generator macro would probably address his issue. (And we're quite close to having one.) Bear in mind you _can_ have mutable private state in Clojure, it's just rarely used. 5) Lazy sequences complect sequences and streams: true. Lazy sequences are not, in fact, perfect for all use cases. That's why reducers and async got introduced. 6) It doesn't feel like a LISP: if that means it doesn't feel like elisp, you're not going to catch me crying. 7) It didn't have a killer app: now it has several. Overall, many of the criticisms are valid, but a) some are design decisions with practical trade-offs* b) some have been addressed since the article was written *I mean seriously, using the JVM is a huge negative in certain ways, but does anyone believe Clojure could have got off the ground if it didn't? Rich Hickey tried other approaches for years before this one worked.