Following up on my last post about the results of the 2013 State of Clojure & ClojureScript survey, I was very interested in digging into the responses to the question “What do you think is Clojure’s most glaring weakness / blind spot / problem?”.
I’ve spent some time categorizing the answers, trying to tease out the trends. Similar to the last category, about half the people answering the survey declined to answer the question so I will assume they are 100% happy. :)
Tooling (111)
The biggest category of responses was around the general area of tooling. The complaints were varied but certainly some of the big areas were requests for debuggers and better IDE environments.
As evidenced in the survey results, Emacs (with nrepl, cider, etc) is the most commonly used tooling environment. While there are some good all-in-one starting environments for Emacs, it can be daunting trying to configure, install, and learn Emacs at the same time you’re doing the same with Clojure. It’s simply not the best on-ramp for someone just looking to get started with Clojure.
We’ve had good support for Clojure in Eclipse with Counterclockwise for some time and the new single download install gets past some of the difficulties I’ve seen people struggle with; also many of the paredit level tools are finally getting good.
The new IntelliJ Cursive plugin, while not included on the survey, is in my experience undergoing rapid adoption. I know some experienced Emacs users that have switched to using it for daily development (including the debugger!) so it’s clearly something to watch closely.
And then we’ve got the newer contenders implemented in Clojure – Light Table and Nightcode. Both of these environments sport many essential features and are advancing rapidly. Beginners are finding success with them – if you lack familiarity with the “classic” editors (Emacs and Vi) and don’t have Java IDE background with Eclipse or IntelliJ, you might find either of these to your liking.
Regarding debugger support, this is a tricky thing (or it would already have been nailed long ago). Clojure code compiles to Java bytecode. The JVM has excellent debugging support via the JVMTI protocol but the relationship between Clojure code and bytecode is complex and not necessarily 1-to-1 – getting good s-expression level support is challenging.
Some other common requests are for refactoring (like Eclipse), validation checking (like lint), and formatting (like gofmt). There are at least partial solutions for all of these in tools like Kibit, Eastwood, Slamhound, tools.trace, etc but none of them are widespread or common (enough). If you’re looking to add value to the tooling ecosystem, expanding the capabilities of the existing tools in these areas would be greatly appreciated based on the responses!
Docs (85)
Documentation was the second biggest area of complaint. In my opinion, there are now a wealth of excellent “learning” books, emerging books on particular topics (web dev, performance), and even several great beginners guides on the web. We also have the venerable clojure.org (a wealth of detailed information from Rich himself), API docs, example sites like clojuredocs.org and , clojure-doc.org for community documentation, a style guide, a wiki, and many other things I’ve omitted or forgotten.
In summary, I see no shortage of documentation. What I do see (and was reported over and over) are problems with organization and discovery, docs going out of date, and filling in the gaps particularly in the areas of best practices and real-world usage.
Some specific suggestions pulled from people’s comments:
- Create a single attractive site that organizes existing resources and is open for contribution in ways that grow quality documentation.
- Official “getting started” docs that provide a good on-ramp for new users (particularly variants friendly to those coming from a diverse set of backgrounds). To some degree, this overlaps with areas already discussed above about tools.
- Update the clojure-doc.org example site to support multiple versions and updated for latest Clojure. Note: this is a project that many people have looked at but no one has pushed over the line. The data exists and there is plenty of work to do.
- Library discovery and documentation could be improved, despite any number of existing efforts in this area.
Another interesting current in the comments are people looking for real-world examples and tutorials about features beyond the beginner level – concurrency, structuring large projects, perf tuning, etc. I take this as a positive sign that people are working in teams and developing real projects.
Performance (69)
By far the largest subset of performance-related complaints were about JVM startup time. Phil Hagelberg has also reported that this is one of, perhaps the highest, complaint of leiningen users as well. In particular, it seems from reading between the lines that at least some of these complaints are from users developing command line scripts or tools. JVM startup time is never going to go away (unless we ultimately have a natively compiled Clojure), but there are likely still things that can be done to decrease Clojure loading time or better control the loading of code.
Beyond startup time, there were many comments about memory size, suitability for scientific or numeric computing, etc. Every Clojure release will continue to provide performance improvements and this will always be a focus area for Clojure development. That said, there may be specific areas (like scientific or numeric computing) where more targeted development (like the core.matrix effort) are necessary.
Errors (54)
The errors category broke mostly into complaints about stack traces and complaints about error messages. The errors have been improving in every release and we have many additional improvements cued up for 1.6 and the release after. I think error messages from Clojure have a couple broad improvements I would like to see:
- A generic mechanism (within Clojure’s implementation) for reporting file/line/col information. Currently there are two separate implementations in the reader and compiler exceptions but many other error scenarios have access to the same information but no good way to report it currently. This could be categorically better.
- Return structured errors made from data whenever possible (using ex-info) instead of munged strings. Tools should be able to use this information to provide much better reporting and feedback.
In general, error messages should tell you what went wrong, where it went wrong, and how to fix it. I think we can make Clojure’s errors categorically better in this regard.
Stacktraces are in some ways tougher – there *is* a stack and it’s a mix of contexts from external libraries, Clojure implementation (in both Java and Clojure), and the user’s program itself. Due to a variety of reasons, these stack traces are just big. There have been several attempts at simplifying Clojure stack traces via post-filtering but this is difficult to do generically without obscuring useful information at least some of the time.
Host (36)
“Host” related complaints were mostly either complaints about JVM as a hosting platform (which just as often praise it as a strength), and a desire for an alternate host. Certainly the most common request was for native compilation. While this is an attractive target if the JVM is an issue for you or if you are interested in fast startup time, it also removes many, many of the Clojure benefits.
Another small group mentioned compilation to native targets like iOS as another desire.
Libs (35)
Most of the complaints about libs had to do with discovery (already discussed above in docs), maturity of docs and libraries, and general complaints that there are either too few or too many libraries in every area.
My personal view is that Clojure represents a typical point along a language growth cycle and people said all these same things when I was working in Java in the early 2000’s. This is a chicken-and-egg problem that is just addressed incrementally over time hand-in-hand with the language. All of us use and contribute to the open source fabric and over time the choices improve.
Very high quality libraries often evolve with the help of commercial entities that use or create them and that only happens as there are commercial companies with teams and projects of sufficient size that they need, create, and find value in releasing or supporting those libraries.
Process (31)
This group of complaints largely covered the process of developing Clojure itself (an area where I have been intimately involved this year). General complaints are: the need for paper contributor agreements, JIRA for ticket tracking and patches, lack of roadmap, lack of committed maintenance, languishing patches, slow pace, Cognitect (formerly Relevance) itself, choice and design of new features.
I won’t take the time to address all of these here. I can say that I think that many of these areas have improved this year and are on track to accelerate next year. Cognitect is committed to providing ongoing maintenance, support, and progress for the Clojure language. Rich and the team have created the current process with the goal of maintaining the highest possible quality and performance for the Clojure that all of us use. At times that means patches require many rounds of development (or are declined) or that we don’t get every fix into a release that we wished, but the end result should be a product that we can rely on.
I will be working on providing better guidance and communication for future releases and road map. Surveys like this are great input for us to understand what the community is seeking.
Others…
Some other categories not yet covered:
- (Mis)-perceptions, marketing, learning, and adoption – all of these were areas where people want more effort to grow the community and eliminate obstacles for new users
- Cross-platform support – particularly creating libs for Clojure and ClojureScript
- Types – this was obviously huge in the last post but showed up in less than 20 comments on this question
Hope you found this interesting!