Clojure Text Editors
A question I and many people have when starting with Clojure is, "which text editor should I use?".
In my case, I have this thing with starting things "right". I heard that Clojurists did things different and I wanted to think as a Clojurist and use the same tools as them. A little research showed me that this meant using emacs because all my conversations up until this point with other Clojurists led me to the opinion that emacs was the "Clojure Editor".
Turns out that choosing emacs was not a great choice for me. I should have stuck with the editor I knew best so that I could focus on being new at one thing at a time. This article will outline some of my learnings when I was just starting with Clojure.
I will work to help new Clojurists by outlining the landscape of "Clojure Editors" which will hopefully help to inform your early journey into Clojure land. My hope is that by documenting my learnings and providing a few words of encouragement we can save some future Clojure developer some time.
Clojure Text Editors
Let's start by introducing the top Text Editors for Clojure(Script) development based on the 2022 State of Clojure Survey.
For professional and hobby developers, the above list contains the editors you might expect to see. The issue is that for newcomers and developers without a strong idea of language specific tooling the above list can feel prohibitive.
One reason for this feeling is that since the majority of the Clojure developers are using the first 3, those must be the ones to use in order to be productive with Clojure.
If you feel this way and don't read any further please take this with you: You DO NOT need to use Emacs or IntelliJ to learn or become excellent at Clojure.
This leads to the next part: which editor should you use?
Which Text Editor to Use
To figure out which editor to use for Clojure development try to answer the following question. Are you:
- A. Experience developer (serious hobbyist or professional)
- B. New(ish) to programming
If you chose A. stick with the editor your currently using. If you chose B. try Atom or VS Code. Continue reading to find out why!
A Text Editor is one of a developer's primary tools because we spend most of our work life inside of it. Given the time we spend in our Text Editor there is something to be said for the satisfaction we derive from using it and its impact on our productivity.
Over time, this satisfaction grows and we begin to associate the qualities of the developer with the editor itself. It becomes a zero sum game.
There are some problems with this mentality and it begins with the fact that tools are tools. They either facilitate productivity, or they don't. Further, the productivity one human gains from a tool, the satisfaction as we called it earlier, is likely going to be different from the next person. You do you.
Knowing this, here's how I define productivity: low startup cost + the utility of the editor itself. Here's what I mean by this:
Startup cost is about whether or not I can use the editor regardless of my operating system and how much configuration I need to get it going on a new development environment.
Utlity is performance and customizability of the Editor. For performance, what I mean is that when I do things like search, open large files or use plugins that are supposed to make me more productive, but I have to literally stop what I am doing and wait for the editor sort itself out, this is no bueno.
Then there is customization. This is a worthwhile optimization which, to me, means I can add features to the editor to improve my workflow. It also helps when I can do this with languages and tool chains I already know.
All of this is to say that these are my preferences that I have built through years of experimentation. If you have been developing for a while, you will have likely gone through a similar process. But let's go back to the original question of "which text editor to choose?".
As I said earlier, if you're an experienced developer, go with the editor you know. If you are a new programmer and don't have deep ties to any particular editor, choose Atom or VS Code. The reason for this recommendation is because these editors are easy to use, work on all operating systems, have active and easy to access communities and support all the modern Clojure tooling one could ever want.
Im comparison, if you choose an editor like Emacs, Vim, or Intellij you are going to spend more time learning and configuring the editors than learning Clojure. You can always try these editors when you feel more accomplished with Clojure and want to optimize your workflow. But at least when you get to this point you will have a frame of reference.
Knowing this, lets move onto how I setup Atom for my development workflow.
My Text Editor Setup
As mentioned, Atom is currently my preferred text editor for Clojure development. The reason? it's portable, easy to setup and customize.
Plugins and Configuration
I have always found that to be productive with Clojure you don't need many tools. This is great because it means I can keep a relatively spartan setup for my Text Editor. Now, let's take a look at the plugins I use and how I configure them.
-
-
Ink only required if your using a version of Chlorine under
0.7.2. Having said this, it doesn't hurt to have Ink installed because a lot of other Atom plugins require it anyways -
Description: Chlorine depends on this.
-
Configuration: None required.
-
-
- Description: Integrate your Clojure REPL into your editor.
- Configuration: Add the Chlorine hotkeys. Here is an example of where to put them.
-
- Description: Automatically balance your parens. Translation? Thinks less about your parens.
- Configuration: The default settings are great, but I recommend enabling
smart mode
Conclusion
Remember that no matter what language you choose, there are going to be a ton of micro decisions to make. The important thing in the beginning is to focus on the language and the learning process and not stress over the tooling. Be good to yourself in your learning journey and try not to obsess over all the details or aligning to the ideal programmer stereotype.