Although you've probably thought about this more than I have, it seems like there's a fundamental tension here. On the one hand there are Java IDEs and code-generation in the sense of (re)writing physical source code files. On the other hand, there are lisp macros in the sense of "an API for the compiler". Fully embracing the latter can obviate much of the need for the former (at least there's a long lisp tradition of this).

But it seems that the Java interop aspect of Clojure complicates this picture. The JVM poking through isn't inherently good or bad (for some people that interop is an advantage, for others it's unfortunate), it's just different from other lisps.

So the point I'm ponderously getting around to making is -- it seems like this IDE will be most useful for people using Clojure as a JVM lang, as opposed to using it as a lisp per se. Would you say that's a reasonable characterization, or not?

If I could weigh in, I don't see why one has anything to do with the other. Many people enjoy using IDEs regardless of what language they're using. Historically, the case has been that statically typed languages benefitted more from an IDE, because there is less ambiguity in symbol resolution (functions or methods are known, typed entities, rather than a string). BTW, Clojure is similar to statically typed languages in that respect in that its dispatch mechanism uses namespaces, so symbol "foo" is well known (either as a function, a macro, a multimethod or a protocol method) symbol in a specific namespace, so that you can easily find its usages or jump to definition.

But even languages with more ephemeral dispatch (Ruby, Javascript, Groovy) can benefit from an IDE. It's often convenient to have an editor, a debugger, and control over the build in a single program (and that's why emacs is an IDE).

So I don't see any connection between IDEs and the JVM. Some people enjoy IDEs and some don't.

I probably didn't explain it well. My impression is that refactoring with an IDE is mainly an artifact of Java, not Clojure.

Also: Lisp macros are a unique kettle of fish. They support Don't Repeat Yourself in ways that plain functions cannot. Whereas an IDE is often used to generate repetitive code in files -- i.e. Automated Repeat Yourself.

> My impression is that refactoring with an IDE is mainly an artifact of Java, not Clojure.

I don't think this should be so. If an IDE could help refactor Clojure - why not?

> Whereas an IDE is often used to generate repetitive code in files -- i.e. Automated Repeat Yourself.

Yes, IDEs do that, too, but IDEs had existed long before this feature came about. There's probably no need for code generation in Clojure, but an IDE could still help with debugging, building, navigating the code, refactoring, and maybe even new things like Light Table tries to do.

I agree that IDE functionality matches the programming language. But IDE features are not a pre-specified set. I'm sure there are many ways IDEs could help Clojure (or any other language).

Absolutely - it's a common misconception that IDEs only generate code for blub programmers. Most IDE functionality, particularly things like refactorings, are not at all language specific and are just as useful in Clojure as in Java. They're a lot harder to implement and it's pretty much impossible to give a guarantee of correctness as you would get in Java or another statically typed language, but it's still very helpful.

The real problem in Clojure is the fact that the syntax is so flexible, which massively complicates symbol resolution and other things. You can't even reliably tell whether the form you're in has a do-body or not!

It's pretty clear that a Clojure (or any other lisp) IDE would have to expand macros. This could potentially have side-effects, but there's really no (good) way around it. Besides, Clojure programmers are used to "passive" tools evaluating forms. Even documentation generators like marginalia and codox actually load a namespace rather than just examine the file, which could have side effects, too.