Emacs is hurting Clojure

Emacs is a very powerful text editor and its popularity amongst Clojurians is easily understood. Emacs has a long tradition in the Lisp communities as it’s written, in a big part, in a flavor of Lisp called Emacs Lisp.

Because of its history, it handles Lisp code wonderfully, with automatic correct indentation, paraedit, integration with REPLs, etc. But Emacs is really hard to use.

Yeah, most Clojurians know how to use it by now and they suffer from bias: “it’s not that hard” they say. Learning Emacs or Clojure is hard enough. Combining them is insane.

Many Clojurians also say it’s worth it. And again, I think they are biased. Human brains are very good at forgetting pain. Other editors these days are also very powerful and although not as much as Emacs, their usage is intuitive so you can achieve a higher level of proficiency just by using it, without spending time and effort in becoming better at it.

The way Emacs is hurting Clojure is by Clojurians maintaining this myth that you need to use Emacs for Clojure. This is not done by simple statements but by a general culture of jokes saying things such as “you are wrong if you don’t use emacs”.

Me, personally, I don’t care what editor you use. If you want to learn Emacs, go for it. Intellij and Cursive is much easier to use and almost as powerful. When I compare myself to another clojurian, productivity is generally decided by knowledge of the language and libraries, not the editor. If you want to use another editor, so be it. It’s better if they understand Lisp code but it’s not a deal breaker for learning Clojure.

I do care about the success and popularity of Clojure. Coupling the growth of the language to the use of an editor that is hard to use and non intuitive makes no sense. It’s hurting us. Even if you are an Emacs power user, when you talk to a Clojure newbie, please, don’t push it down their throats.

Like this:

Related

38 Replies to “Emacs is hurting Clojure ”

I don’t think rich hickey uses emacs. Clojure doesn’t predicate the use of any editor, let alone emacs! Clojure tooling built with emacs does though, for obvious reasons.

The point about emacs is its amazing customizability and the availability of major and minor modes for every conceivable language. After achieving vi proficiency, I switched to emacs which was very painful. But, it has paid rich dividends and I am happy to have emacs as my main development tool.

The Clojure community, at least here in London, pushes Emacs quite hard. Most people that I see using Emacs are not using this amazing customizability to great productivity. Add pair programming and it only hurts productivity as all setups are unusable by anyone except their own owner.

Every time I’ve seen Rich present so far, he’s using a version of Emacs (I believe he was using Aquamacs at one point). The same is true of Stuart Halloway and several others who present regularly about Clojure. The annual State of Clojure survey continues to indicate Emacs is the most widely used editor in the Clojure community, so I’d agree with Pablo that there’s a very strong sub-current of “pushing Emacs”.

Personally, I’ve gone back and forth. I used Emacs 20-ish years ago (the end of 17.x through the start of 19.x) but moved on to other editors and later IDEs. When I first picked up Clojure in 2010, I used TextMate and SublimeText, then CounterClockwise/Eclipse, then back to Emacs, then LightTable for about a year, then I went back to Emacs. Different people choose different editors for different reasons. If someone is coming to Clojure from Java and they already use Eclipse or IntelliJ, it lightens the learning curve to suggest CCW or Cursive. The ClojureBridge organization generally uses NightCode for their introductory workshops as a good compromise between simplicity (of installation as well as of use) and Clojure-friendliness.

At work, we recommend that if developers want to use Emacs, they at least consider a fairly standardized setup (Prelude — well-documented — with a small suggested customization to make it easy to run Expectations-based tests). I haven’t seen customization so extreme it makes pair programming any more difficult.

If you replace ‘Emacs’ and ‘Clojure’ with ‘Hand operated mini excavator’ and ‘Ditch Digging’ how would you paraphrase the issues being faced by the community differently? Is it a human thing or a tool/language thing?

Let’s say you have two hand operated mini excavators, one has a set of joysticks with labels and one has a unlabeled row of buttons. The one with buttons has 100 buttons and you can assign different operations to any of those buttons. The one with joysticks is editors with modern UI and apparent functions, such as IntelliJ IDEA, Sublime, Atom, even Notepad; while the one with the buttons is like editors with non-apparent interfaces, such as Emacs and Vim.

The buttons can be more efficient and effective because power users can program them, but they do slow you down at the beginning. What I see in the developer world is that most people never reach those levels anyway and even if they do, their lose of initial productivity might have been big enough to offset the gains (of course, it’s a different matter for the 20-years-of-using-emacs kind of person).

Emacs is opaque. The only way to use it to a relative medium level of productivity is by learning a lot of commands that are not readily apparent. Emacs cannot be learned by inspection. Setup is not very important here. If you are an Emacs user, think about Vim, is it apparent how to use Vim or is it opaque? Does it require sitting down to learn it or can you learn it as you use it? Same is true for Emacs.

I would have to disagree with you that Emacs is opaque in this day and age. I think most people can reasonably expect to install the GUI versions, start clicking away, and learn the rest as they go along. I also disagree on two other points with the OP generally: a dev tool that you will use professionally is very much worth the trouble of learning properly. This goes for any tool. Which brings me to the second point: I don’t think other tools like (especially) IntelliJ are that much simpler to use productively than Emacs that it becomes a serious discussion. They all have their learning curves and none of them is as easy as we would like to imagine.

Actually, I find now I have a final third point: if the community is settling around a particular tooling (Emacs, paredit, lein) it is difficult to recommend newcomers to use something else because they will be hampered by missing out on the active community that could have helped them with tooling.

Emacs on its own is relatively opaque and takes time to learn, but I’ve found that having never worked with IntelliJ, Cursive was actually just as difficult for me to learn. By far the best thing I’ve found in terms of learnability is Spacemacs — which provides an insane wealth of functionality out of the box, and an incredible self-documenting system. I allows either Vim or Emacs traditional keybindings, but as you type, shows you what commands could be added to the chord. If you haven’t checked it out before, just look at this walkthrough of some of the most basic commands, (remember, this is out of the box) and consider recommending Spacemacs to the next beginner you meet https://www.youtube.com/watch?v=ZFV5EqpZ6_s

Emacs is opaque, and incredibly bloated… I agree with J. Pablo Fernandez. It’s not intuitive at all, and whether or not you use a GUI version doesn’t matter – Emacs’ GUI is very light/thin and not well done at all. It’s a “do only as much as required, and it doesn’t have to make sense” hack job. In order to make Emacs work well in a “true GUI,” they’d need to basically redesign it…

SlickEdit, for example (any only mentioned for purpose of comparison), and a few other editors are equally as extensible as Emacs (same basic design… core written in C or C++, then most functionality written in the extension language). They all work better in GUI Environments like than Emacs. They behave like proper GUI applications. Emacs does not. SlickEdit also has proper keyboard emulation for about 10 different editors (Emacs, Epsilon, BRIEF, CodeWright, Vim) and has default CUA key bindings, which means that the basics are the same as the desktop environment most non-macOS users are used to (Windows, Linux, UNIX DEs).

As a result, you can sit down and use SlickEdit from day one and still be able to get things done without feeling forced to switch back to a different editor. Basic Keyboard Shortcuts are the same as what you’re used to. Windows and File Management is handled in an expected way. Settings are handled in an expected way. Clicking on Search will prompt you in an expected way.

Emacs is the complete opposite. It’s designed for keyboard navigation on a type of keyboard no one has access to, anymore, and the shortcuts are illogical. Emacs has poor emulation of other keyboard layouts built-in (the CUA mode is worst than most editors’ Emacs emulation – by far – for example, though Viper is apparently quite good; I’m not a vim user so I can’t personally vouch). The menus are laid out in a way that is illogical to most users _going to it_, because Emacs is not designed with the host OS’ conventions in mind. The mouse support is rudimentary, and functions in ways that is not in line with other GUI applications. Selecting Options/Actions often prompts you in unexpected ways (text in status versus graphical mini-dialog/window). File and Windows Management is completely different. The documentation uses archaic terminology which is illogical to users of modern operating systems, as it alludes to actions actions on old machines which do not map to modern desktop operating systems (i.e. “Visit” a File vs. “Open” a File).

I also didn’t find the Emacs community at places like the Freenode IRC channel to be very helpful. Every inquiry is met with “Google it.” Annoying when you need human explanation because the documentation’s terminology is laughably bad.

Emacs itself is a piece of software; does stating that *it* is hurting Clojure make sense? I run a Clojure meetup and use Emacs exclusively, yet I made Youtube videos for the group showing how to get started for those preferring Atom or Sublime Text to Vim, Emacs, or a big IDE like IntelliJ+Cursive.

Out of the box you can discover and access Emacs’ functionality through the menus like any other application. The preferences menu item even opens a browsable menu system for configuring Emacs to your liking, no fiddling with config files or Emacs Lisp required.

When it comes to actually writing or editing text, Emacs works the same as any other editor as it’s not modal like Vim. The movement key commands in all major operating systems are the same as Emacs by default, knowing or not knowing how to use them to move words at a time etc is not unique to Emacs nor adds any difficulty. With *any* editor many people start memorizing keyboard shortcuts for common tasks.

After installing packages, the menu often allows access to major functionality provided by those plugins. This isn’t as pretty/easy as Atom, but you could argue is easier than Sublime Text, even installing Cursive in IntelliJ could be considered a bit fiddly.

I’ve honestly not encountered any pressure to use Emacs ever in the community, but invested in learning more about Emacs after really liking CIDER for working with Clojure. While Cursive is a very powerful IDE; the draw of Emacs is nearly *unlimited customizability*. This is a gem for those of us that are very picky and opinionated about the behavior of our editor (my Emacs is indistinguishable from Vim when editing text for example).

I think it’s awesome how many choices in tools we have that fit different styles and personalities. For those interested in a polished highly-customized approachable Emacs setup with great discoverability of features, check out http://spacemacs.org ; it has a huge (and friendly) community.

I take your point about some of the London Clojure community ‘pushing’ emacs a bit, I am sure I’m as guilty as anyone of this! We do it tongue in cheek and really don’t care what editor people use as long as they have fun with Clojure but perhaps we should be more sensitive to this bias. Plenty of London Clojurians use Vim/Fireplace and Intellij/Cursive too.

I personally don’t mind what editor people use although I would encourage people to use something that has good REPL integration. I use Intellij with my Java (and sometimes Scala) hat on but I’ve never really picked up Cursive simply because I went through the pain of learning Emacs first before Cursive existed.

For me the only point at which it matters is if you are pairing and I’ve had the same issues with other languages as with the exception of .Net, you still get variations in IDE/Editors.

I think the problem we really need to solve is how to rapidly share code so that we can pair on whatever editor is most productive for the current driver. Git can help here but push/pull still takes a bit long for my liking.

I’ll save my preaching for the Church of Emacs meetups from no on. ;-)

The difference in other IDEs is that often the default functionality is left in tact. Emacs is often modified in ways that change the behavior of a lot of basic functionality. So, this issue is exacerbated with Emacs, often. There is also a lot of duplication within the Emacs ecosystem, and setups tend to be a lot more personal to each developers. In the .NET or Java World, many plug-ins are fairly ubiquitous to the point that they predominate in usage (Visual Assist, CodeRush, or ReSharper – for example). This makes this less of an issue.

Most Visual Studio users do not use highly customized key bindings and things like that (i.e. VIPER) in their IDE. Many (if not most) Java developers learned in IDEs like Netbeans or Eclipse, and therefore feel no need to modify the bindings to a great extent.

However the only argument against is that it is “really hard to use”. I would understand if you said something like “oh it’s really hard to use and in the end it doesn’t pay because there aren’t that many advantages comparing to other IDE”. But no, you argue against it on the basis of being hard. I’d say that shying away from things that “are hard” but are worth the investment, ins’t a desirable trait to have in this line of business.

That being said, I don’t even think that emacs is that hard at all. Start with a good set of tutorials, I’d recommend “Mastering Emacs” and work through them until you have a decent and productive workflow. In the end you’ll find out that mastering Emacs is as hard as mastering other IDE. I think this would be more helpful to newcomers.

If that was true, Cursive would not have any emacs key binding option. Of course emacs is giving more benefits than Cursive. But Cursive could give _other_ benefits so it is best to combine it by using emacs key bindings in Cursive.

My comment was to your statement: “If you have two options giving you the same benefit,”. If emacs keys and editing mode would gain exactly the same as just using Cursive as a normal text editor, why would such key binding support exist?

Btw, I know the answer, since I have tried both, and prefer using either emacs or some Jetbrains editor with emacs support. If the IDE has no emacs support, it is almost not better than using emacs directly.

When it comes to evaluate the effect of different tools are having on the community, your preference matter as much as mine, which is nothing. What matters is what is happening in the community, what happens with newcomers.

For example, a friend of mine uses an Ergodox keyboard without any labels on it (I uses a Kinesis Advantage and I might purchased the unlabeled keys at some point). He assigned dedicated keys to open parens, square brackets, etc. His keyboard is much more efficient than yours or mine at coding Lisp now but that doesn’t mean is the best choice for everybody. If people would have to use an unlabeled keyboard in Lisp mode to code Clojure, nobody would ever touch the language. Emacs is mostly unlabeled and thus, not apparent, were IntelliJ and Cursive are. I’m not saying that IntelliJ+Cursive is the answer, it is an answer. Some people in this thread have mention others (Atom, LightTable, although I’m skeptical about the last one).

What I’m trying to get to is that some tools are discoverable by the act of using the tools and some aren’t. Non-discoverable tools have a steeper learning curve and thus act as a road block for beginners (beginners that are already learning a programing language, which is by necessity a non-discoverable tool).

By the way, I’m not uncovering any hidden truths here. This is a basic principle of UI/UX and making tools more apparent and discoverable has seen a lot of research and work in the past 30 years. For an example of this type knowledge: “Don’t make me think” and “The Design of Everyday Things”.

Because people coming from Emacs will find it easier to use Emacs key bindings; not because the Emacs key bindings are superior. I don’t think Emacs advantage over IntelliJ+Cursive would be which key-bindings it’s using.

While I’m sympathetic to your argument that Emacs is unnecessarily painful — let’s face it, it’s a crock of outdated shit — I’m unsympathetic to the general point in your later commentary that tools should be designed for beginner friendliness, and I am outright opposed to this being a fundamental UI/UX principle.

Professional tools in any serious industry do not have interfaces designed for beginners. They require hours and hours of training. This is not because the designers of those tools wanted to shut beginners out. It’s because once you reach a certain level of proficiency, the crutches beginners need and want are not only irrelevant but can become barriers to flow. And flow is the most precious resource an expert has. Anything that prevents it should be shot on sight as a matter of moral principle.

The missing thing here is a modern programming environment that rewards sufficiently graduated skill level. Balls to worrying about upsetting beginners — plenty of alternatives will continue to exist for them, and any beginner that refuses to learn a life skill because “omg I have to learn something” can categorically go and fuck themselves.

I agree with this article. I am in the process of learning Clojure for the last 3 months, as well as Emacs. I have been using IDEs for the past 15 years( Netbeans, Eclipse, Visual Studio).

At first, the attraction of something new, created high interest in me to learn Emacs. I learned the editing keys, the package manager, the configuration file, and CIDER. However, now that I have an understanding and can do some stuff, I really don’t like it at all. It feels so old like when I was coding C in the Brief editor. I reflect back on all the effort it took to learn Emacs to become operational and wish I had not gone down that road. So I am trying out Cursive now.

My impressions may be do to my history with working for IDEs however, and others may find Emacs rewarding.