The Ideal Clojure Development Environment

This is my personal nearly-stream-of-consciousness scratchpad for what I'd like to see in a Clojure development environment. The comments are available below if you'd like to throw your 2¢ in – and I'm sure I'll glom others' ideas into this space from various sources. That said, I'm decidedly hoping to avoid beating the usual horse carcasses (fossils, really) that are often found scattered across this topic's landscape.

The above is all a long way to say: these are my opinions, don't get all twisted about them.

NOTE I have posted a Google Spreadsheet form to gather market data from those interested in paying for a polished Clojure development environment. If this describes your sentiments, do add your 2¢, and hopefully help convince some enterprising tool vendor to build the ideal Clojure environment. Petition / Market Research: For the development of a commercially-supported, polished Clojure development environment

Background

The motivation for writing this up came started with a tweet of mine:

I'd love to pay for a super-polished clojure dev env. I've got $500 (every two years, say) for whoever can make it happen. Seriously.

From there, Seth Schroeder asked if I was keeping "a wishlist of wants and needs for such an app", and Michael Fogus said that such a list would be very welcome. And hell, it's hard to argue with fogus. :-)

Current state of play

Check out the Getting Started with Clojure page, which AFAIK is a comprehensive list of available environments. My latest impressions of promising environments are near the bottom.

I think it's impossible to really know what the breakdown of environments in use by Clojure programmers – there's just not enough of us yet to avoid getting swamped with sample bias, regardless of your polling method.

Let's get on with it (with not much order for now)

(In hindsight, I realize I should have made this a table, so I could check off which features are provided by each available environment; that'll be in v2, I suppose.)

Thoughts on available environments

My evaluation process for a new or updated environment is to just try to do what I'd do in a normal day: open a project or two, open some files, do some editing, open a REPL, etc. When I hit some difficulty or serious unpleasantness, I walk away (sorry, there's only so many hours in the day).

(FYI, these notes are current as of 10/26/2011; I don't want people to get mistaken impressions after I've neglected this section/page for six months.)

Counterclockwise (Eclipse)

I've been using Counterclockwise and Eclipse full time since fall of 2010.  After struggling with significant difficulties with NetBeans itself for some months (segfaults suck; on the other hand, Enclojure itself was always fantastic), I had to find another home.

Counterclockwise's REPL was previously not in good shape though.  After deciding where I'd place my bets, I ended up designing and implementing nREPL (a tool-agnostic Clojure REPL server and client), and rebuilding the REPL support in Counterclockwise from scratch.  The result made it possible for me to use it for real work, and I've enjoyed it ever since.

The recent v0.4.0 release has really brought Counterclockwise into its own, though.  Its namespace browser is great, code completion is nearly as good as Enclojure's (and approaching what I've seen in SLIME), and the REPL and editor continue to improve.  FWIW, I'm currently working on some enhancements to nREPL and Counterclockwise to support richer REPL interactions than are currently possible in any mainline Clojure environment, and there are lots of things in the pipeline that make me confident that I'll not have to switch my tooling for years to come.

(Especially with the DOM-like UI and css styling possible in the forthcoming e4, I can imagine a nouveau emacs-like environment (i.e. deeply-customizable UIs and behaviours) coming out of a combination of e4 and clojure.)

Enclojure (NetBeans)

Enclojure, the plugin for NetBeans, is my current tool of choice (NOTE: I started using Counterclockwise and Eclipse full time in fall of 2010), and has been since I started seriously programming in Clojure ~summer of 2008. I think it was the first Clojure IDE plugin, and IMO, it's still the best. Why? It checks off more of the requirements listed above than any other option. :-) It definitely has a variety of issues, but no showstoppers; it gets the job done well, and the base NetBeans environment is sufficient.

La Clojure (IntelliJ)

La Clojure is notable in that its development is sponsored commercially by JetBrains.

The baseline editor functionality is probably the best of all of the IDE plugins, with fast and excellent clojure symbol completion – though only of core, it seems.

Things fell down pretty fast when I tried to get a REPL going though – La Clojure uses (what I consider to be) the fundamentally broken notion of a clojure platform (even though my project had a clojure and contrib dependency in its POM). Despite futzing with my project's clojure framework setup quite a bit, I still wasn't able to create a REPL – attempting to do so popped up a "No Clojure base path defined" error (or something to that effect).

Having professionally used IntelliJ in the past for full-time Java development, I know JetBrains can produce killer tools; hopefully we'll see great things from them as La Clojure matures. Good on them for diving in, though.

The emacs world

It'd be hard to talk about lisp environments without talking about emacs. I received at least three or four replies to my original tweet suggesting it…including Dan Larkin's, to whom I responded:

you must have missed my "polished" qualifier, eh? ;-)

Though I'm a thoroughgoing pragmatist with regard to my tooling, I confess a degree of bitterness towards emacs for a variety of reasons, both technical and social. As a historical note, I've made two serious attempts at using emacs full time – one many years ago, the latest a two-month run in 2008. In both cases, I was foiled by UI issues, a lack of adequate JVM tooling (and no, the JDEE doesn't cut it), and a complete mismatch between myself and what I'll smugly call the "emacs culture". On the last point, I'll simply say that I'd always rather get real work done than futz with my text editor, and I can't imagine ever being willing to spend as much time customizing and tweaking my development environment as really productive emacs users.

There's no doubt that emacs provides a base for very capable lisp tooling – inferior-lisp, swank and slime, etc. etc. make it an easy base to build on. Where things seem to go pear-shaped are in the areas of UI/UX and any functionality that is JVM-centric.

Like I said, I'm a pragmatist, and will go wherever my capability and leverage will be maximized – so if emacs somehow were to change enough to meet the above criteria (or, meet more of the criteria than whatever my favored environment was at the time), I'll use it with joy.

Actually, I think an ideal path would be if emacs (or a functionally-equivalent editor/scripting environment) could be hoisted into, say, Eclipse – that might come very, very close to satisfying the vast majority of my wish list items. Again, this is why counterclockwise (or some other eclipse plugin) may have a big leg up given what's coming in e4.

Lispworks

OK, so Lispworks is a Common Lisp environment. It has no Clojure support, but I dare its authors to try. Why? My list above can probably be summarized by "Eclipse + LispWorks for Clojure". It's easily the best CL environment I've ever used, and I'll bet they could put together a killer Clojure plugin for one of the major IDEs. I doubt that will ever happen, but it's a nice thought experiment and shorthand for what I'm aiming for.

1 Fundamentally, I think people building clojure plugins and such should simply co-opt enclojure's REPL components (Eric Thorsen suggested bringing them into clojure-contrib at some point (can't find the link now, sorry), and I think that, or something similar should definitely happen).

2 This concept is either a valid and useful accommodation for new/less advanced clojure programmers so as to hide the necessary yet dull complexity of what versions of what libraries your project depends upon, or a misguided tooling holdover from other languages that are older and move less swiftly than clojure does. It's certain that that rate of change is partially attributable to Clojure's relative youth, but I suspect that Clojure's rate of change will always be higher than most languages, given its relative simplicity. We shall see – maybe in another year, we'll all switch to 1.3, and virtually everything will be in libraries for the next 5 years.