Cursive Clojure: A Clojure IntelliJ plugin(cursiveclojure.com) |
Cursive Clojure: A Clojure IntelliJ plugin(cursiveclojure.com) |
I'm planning to release this as a commercial PyCharm-style IDE, at a similar price point. I've done this in consultation with JetBrains, in case anyone's concerned about that.
Edit: some clarification.
TIA
why isn't there a clojure option in the new project menu, like, groovy for example?
I suspect that you'd probably find that the percentage of Java devs using IntelliJ has gone up a lot in recent years too, their market share and mindshare has increased massively recently. I'm not aware of any stats though (and I'm not sure how accurate they would be if there were). Google recently switched from Eclipse to IntelliJ for the official Android development environment, for whatever that's worth.
It'll be similar to PyCharm in that the standalone IDE will be basically a cut-down Community edition plus the plugin, right, although it can be customised more heavily for Clojure if required. The licensing will be the same for the plugin and the IDE (i.e. your licence will work for both), so if you already own IntelliJ Ultimate it would make sense to stay with that. Unfortunately I don't have the luxury of offering the plugin free to IntelliJ Ultimate users as JetBrains can do with PyCharm.
Exactly.
Good plugin BTW. I like the jump to Java code (I work on a mixed Java/Clojure project), and was very happy to find out that renaming a Java method fixed the Clojure calls, too. And find usages works across languages! Keep up the good work!
EDIT: One problem I've found: If a function is defined not with defn but using a macro that expands to defn, then the symbol is not resolved.
EDIT 2: Just checked: refactoring and find usages works with Kotlin code, too (in a mixed Clojure/Java/Kotlin project).
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?
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.
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.
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).
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!