Ha, this is funny. I came here to say that this has been exactly my impression (sans Java interop warts since I haven't done much there).
There is a lot of missing documentation -- and by that I mean high-quality, contextual, human-readable, practical documentation -- though the community has been working to remedy that.
There is a particular definition of "culture of brokenness" that I'd agree with but there are a lot more that I wouldn't. I'd have to hear the author's definition of what he means by that before I agree.
That being said Clojure is downright beautiful. I wish I had opportunity to work with it more.
To me the most frustrating thing about programming in Clojure (not that I'm generally frustrated by doing it, in fact I love it) are the totally cryptic/useless error messages, especially syntax errors that don't contain a line number (or they do but it's invariably 0).
Thank goodness for syntax-coloring editors or it would take me hours to track some of these things down.
To be honest I have never found any functional language that gives anything near helpful error messages. I have found that the best way is not to read the error messages but to pattern match on the phrases. Sounds like a downside but the benefit is it takes only a mere fraction of a second to look at an error message and guess what is wrong once you get comfortable. There are not too many patterns either.
I can but agree with this, Clojure rivals template-heavy C++ in GCC for the uselessness and pointlessness of the humongous heaps of cryptic error messages it produces.
Not that this is an excuse, but once you know a bit more about how Clojure and the JVM work, stack traces become a lot easier to interpret. Most of the time, there's at least one line in the stack barf that tells me exactly where to look to find the problem.
This may actually be a bad thing, because it disincentivizes those who have the ability to fix things to be more newbie-friendly.
I've been wondering if the fix would be as simple as filtering stack trace entries generated by higher lower level code (ie, from Clojure itself rather than the application code.) It seems like such a simple fix that I wonder why it hasn't been done.
The problem is that these require a running, working system to format and print the stacktrace (as well as inspecting the state of the Clojure runtime). Unfortunately, uncaught exceptions will also quite often FUBAR the REPL, if not the entire JVM, meaning that improved stacktrace tools can only work some of the time, and will sometimes even make things much worse (if the JVM throws an exception from within the stacktrace formatter itself.)
I have heard many people complain about the documentation (in fact I've seen you do it before ;)). But I think the documentation is great; concise and informative. I learned more from the docs (the reference) on clojure.org than any book.
Yeah when I was investing a lot of time in getting to know Clojure better I was definitely a spoiler wrt better documentation. But it's only because I love the language.
There are a couple of very recent texts that have been released on Clojure that can all be used in combination to learn it. Programming Clojure and Clojure Programming are both at most 3-4 months old. Taken together, the documentation is fairly extensive.
I was surprised by the lack of documentation comment in the article. I own four useful Clojure books, and along with effective web searches, any roadblocks are quickly jumped over.
That's a starting point, sure, but it's not necessarily a great one. Books are books. They take time to find, money to purchase, time to be delivered, and then they take time to read and pursue.
When I started learning Django, the key thing which everyone pointed me to was a simple screencasted tutorial where a man with an Indian accent started showing me how to write a wiki in Django. It wasn't pretty but it was a way to bootstrap myself enough into the Django mindset that I could start learning how to do database-driven web design. Then I could sit down and read the docs and they mostly made sense. Before that, Django was impenetrable; just seeing "oh there's a data model which is embodied within the databases, you have to run 'syncdb' first to get this working," etc. was a harrowing way to do 'Hello, World!'.
I have a little advantage with Clojure because it is a Lisp and I've done Lisps before when I followed the SICP video lectures and learned some basic Scheme. In this respect coming to Clojure is much easier for me than working with Haskell. (Although seriously, the Haskell interpreter is so much easier to use--please, someone implement libedit or another readline clone in Clojure and put it in the Clojure main distribution so that the 'up' key gives me the last line.)
But nonetheless, this is the first time I've seen a clear attempt to say, "here, let's work together to build a substantial program in Clojure." There is so much you can learn from such approaches that I think it's crucial to have some. Even this first tutorial page starts talking about how you should do some 'lein trampoline run' call rather than trying to do things with Clojure directly: that's something crucial which was never communicated to me via the Clojure web site. I now get to read up on Leiningen and what the hell that is for, as well as perhaps what the hell is in clojure.contrib that they also don't tell you about on the clojure.org "Getting Started" pages.
Seriously. This sort of thing is the difference between `django-admin.py startproject website` and creating a new text file which starts `import django`. Both are technically ways to develop a new site with Django, but the first one is the Correct Way To Do Things. (And fortunately djangoproject.com tells you to do things this way.)
You just pick up so much implicit stuff when you follow someone along as they program a very simple nontrivial application.
I think one thing that's become obvious to me over time, and was only briefly touched on at Uni, is how important the supporting ecosystem around a language is - in particular, the build tools. When I first started programming, all I'd do is grab the compiler, and run with it (javac, python, ghc, whatever). Now, however, I've become aware that I should always be using build tools - cabal, leiningen, rebar, go (has one provided with the language), maven, sbt, django-admin (kinda), etc.
I think this is something that needs to be better communicated and understood. When you pick up a new language, you also pick up its tools, and the landing pages for languages need to better communicate which build-tool is "blessed".
Lots of the discomfort in Clojure is a function of what also makes Clojure really great: fast moving, willing to break compatibility to keep making it better.
Eventually the language and platform will become more stable. I am not sure, but we may be at that point now, or very soon.
I must admit I lost a little bit of time this morning creating a new Noir project because of lein1 vs. lein2 issues. I am also trying to decide whether or not to go back to my really old projects and update to Clojure 1.4, refactoring of Clojure contrib, etc.
> please, someone implement libedit or another readline clone in Clojure and put it in the Clojure main distribution so that the 'up' key gives me the last line.
This works fine for me using Leiningen 2. All the usual libreadline functionality is there, and there's tab-autocompletion too.
This has not been my impression.