Emacs is hurting Clojure 

by

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.

Thank you.


38 responses to “Emacs is hurting Clojure ”

  1. Phil Marlowe Avatar
    Phil Marlowe

    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.

    1. J. Pablo Fernández Avatar

      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.

    2. Sean Corfield (@seancorfield) Avatar

      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.

  2. Ricky Avatar

    For a lisp beginner, would you recommend alternative editor or should I use Emacs (… perhaps temporary)? thanks!

    1. Ricky Avatar

      okay I find it …. Cursive… sorry for bothering you!

      1. J. Pablo Fernández Avatar

        Yes, I really like Cursive. Someone also mentioned Atom might be a good choice but I cannot really recommend it as I never used it.

  3. grettke Avatar

    Thanks for sharing your experience and thoughts.

    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?

    I’m reading it as the latter?

    1. J. Pablo Fernández Avatar

      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).

      Does it make sense?

      1. grettke Avatar

        Gotcha! Thanks for elaborating. My advice for people learning Racket (Scheme) is to use DrRacket for that very same reason.

      2. grettke Avatar

        Gotcha. Yes. Thank you for your reply.

  4. The Donald Avatar
    The Donald

    Emacs can be difficult to get setup properly but I don’t really see how you can claim that it is hard to use. Even when the setup isn’t optimal, it’s still quite usable.

    1. J. Pablo Fernández Avatar

      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.

      1. Yawar Avatar
        Yawar

        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.

      2. mkotsbak Avatar
        mkotsbak

        True, but if you are writing code 8 hours a day, why would you not spend some hours learning the best tool for the job? It is very different from someone that just writes something now and then.

        The main advantage og emacs are the keys that avoids use of arrow keys, page up/down etc so that you don’t need to move the hands away from the qwerty placement.

        A lot of editors have emacs keymaps support, including IntelliJ. So it is possible to get the best of both worlds!

      3. mkotsbak Avatar
        mkotsbak

        I do the same when writng Scala, just use IntelliJ with emacs key scheme and I immediately already know a lot of editor commands for e.g. split screen, changing file etc that avoids mouse usage.

      4. mkotsbak Avatar
        mkotsbak

        Cursive is also supporting emacs keybindings:
        cursive-ide.com/userguide/keybindings.html

      5. Conor White-Sullivan Avatar

        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

      6. Anon Guy Avatar
        Anon Guy

        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.

        I settled on NEdit on Linux/Unix. Very good GUI editor.

      7. Justin Megawarne Avatar
        Justin Megawarne

        The only intuitive interface is the human nipple.

  5. […] Pablo Fernández has another one of those posts that drive me crazy. His thesis is that Emacs is hurting Clojure because it's hard to learn and use or something. It's a silly, even risible, argument. His […]

  6. Chad Stovern (@chadhs) Avatar

    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.

  7. agambrahma Avatar

    Hi, thanks for the writeup, small typo: in the sentence “most Clojurians know how to use it by know”, the second “know” should be “now”.

    1. J. Pablo Fernández Avatar

      Thanks! Fixed.

  8. Mike Zamansky (@zamansky) Avatar

    Decided to write up some thoughts on the topic: http://cestlaz.github.io/posts/user-friendly/

  9. chrishowejones Avatar

    Hi Pablo,

    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. ;-)

    Regards (as always),
    Chris

    1. J. Pablo Fernández Avatar

      A colleague of mine proposed pointing two editors, Emacs and Cursive, to the same directory and one starts the REPL and the other one connects to it. It might actually work.

    2. Anon Guy Avatar
      Anon Guy

      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.

      https://polldaddy.com/js/rating/rating.js

  10. gdjsky01 Avatar
    gdjsky01

    Fantastic and correct! Thanks for writing this up. If Clojure is EVER to become mainstream ( and it is not close ) we need to show something other than a 30+ year old editor in a terminal.

  11. Flávio Sousa Avatar

    You seem to give a lot of arguments in favor of Emacs:
    – very powerful text editor
    – written in Lisp
    – handles Lisp code wonderfully
    – correct indentation
    – paraedit
    – integration with REPLs

    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.

    1. J. Pablo Fernández Avatar

      All those good traits are true for Cursive as well, but you don’t have to go through any tutorials, just download it and start using it.

      If you have two options giving you the same benefit, one being hard and one being easy, the effort to achieve the hard one is not worth it (unless you are seeking a challenge for a challenge’s sake).

      The only case in which reading the manual for Cursive is necessary is to use structured editing (paredit or parinfer), but you don’t have to.

      1. mkotsbak Avatar

        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.

      2. J. Pablo Fernández Avatar

        What’s your rationale for equating the existing of Emacs key-binding to having to read tutorials to learn to use the tool?

  12. mkotsbak Avatar
    mkotsbak

    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?

    1. mkotsbak Avatar
      mkotsbak

      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.

      1. J. Pablo Fernández Avatar

        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”.

    2. J. Pablo Fernández Avatar

      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.

  13. Justin Megawarne Avatar
    Justin Megawarne

    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.

  14. EScott Avatar
    EScott

    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.

Leave a Reply

You may also like:

If you want to work with me or hire me? Contact me

You can follow me or connect with me:

Or get new content delivered directly to your inbox.

Join 5,043 other subscribers

I wrote a book:

Stack of copies of How to Hire and Manage Remote Teams

How to Hire and Manage Remote Teams, where I distill all the techniques I've been using to build and manage distributed teams for the past 10 years.

I write about:

announcement blogging book book review book reviews books building Sano Business C# Clojure ClojureScript Common Lisp database Debian Esperanto Git ham radio history idea Java Kubuntu Lisp management Non-Fiction OpenID programming Python Radio Society of Great Britain Rails rant re-frame release Ruby Ruby on Rails Sano science science fiction security self-help Star Trek technology Ubuntu web Windows WordPress

I've been writing for a while:

Mastodon

%d bloggers like this: