Why Does EmacsLisp Suck?

I am going to go out on a limb here and defend Elisp. I think that for what it was designed to be (a complete scripting language for a text editor) it does everything that it needs to do very well, and much more. Much of these arguments do basically boil down to "Emacs Lisp basically isn't [some other language]", or misconceptions about the philosophy of how the system is designed.

I have hacked a considerable amount in both Elisp and CL and I can state that I actually prefer the way Elisp does some things over the way Common Lisp does--this is not to say that CL does things the wrong way--the matter is that they have different purposes. Emacs combined with Elisp in itself constitutes a complete programming system; all of its components are designed around it.

The language being integrated into Emacs makes writing Elisp programs a very fluid and intuitive experience: things like the fact that the documentation and the place where a function was defined is available at any time makes /understanding/ the system easy, and the actual documentation itself is often quite well written, and the Info manuals will most often explain everything you need to know about a package. Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does.

Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. The added complexity that multithreading would add to Emacs would seriously outweigh the usefulness it would provide. Emacs already has a decent process model, and having to deal with only a single shared state makes programs much cleaner.

At the very least if it all comes down to a dick measuring contest, the base GNU Emacs provides 100000000x more utility in its packages in a fraction of the memory space than VS code or Vim ever will. Emacs has its fair share of killer apps like Magit that provide such a clean interface to something that it makes using it worth it for that alone.

This wiki page raises some good points, for example, the stateful nature of some of the APIs:

  Instead of returning a data structure of the match results (eg from a call to match-string), the match results are mutated in global memory and accessed in separate function calls. This is both less functional in style and more error prone. For example, if save-match-data is not used appropriately, then library functions can trample on the match data which a higher level function is in the middle of using.

But in some other parts it reads like two or more personalities stuck in the same body shouting at each other using the same mouth:

  EmacsLisp Isn't Scheme

  This, from my highly unscientific sample, is far and away the most popular reason EmacsLisp sucks. Well, that’s good to know. EmacsLisp is also not Perl, or COBOL, or IBM 1130 assembler, or a bicycle, or an orange. Thanks for the help!

This seems to be missing the elephant in the room - elisp doesn't suck, it is just a lisp. It is annoying having to learn a specific lisp just to edit Emacs, but whatever. Other lisps are better if you want to add lisp to your application.

The Emacs data model sucks. There are APIs that do who-knows-what combined with your personal extensions that modify behaviour who-knows-how, figuring out how to describe UI components is no fun, text editing is surprisingly hard from a programmers perspective, there are decades of accumulated different ways of doing things and it is unclear where to start or what has been obsoleted. The names made sense in the 70s but unfortunately it is 2024 and "Windows" means something different now. I wouldn't even exactly blame Emacs for any of this since some of it seems to be essential complexity of the domain.

EDIT Example, picked completely at random:

https://github.com/clojure-emacs/cider/tree/master/dev

    (defun cider-tramp-prefix (&optional buffer)
      "Use the filename for BUFFER to determine a tramp prefix.
    Defaults to the current buffer.  Return the tramp prefix, or nil
    if BUFFER is local."
      (let* ((buffer (or buffer (current-buffer)))
             (name (or (buffer-file-name buffer)
                       (with-current-buffer buffer
                         default-directory))))
        (when (tramp-tramp-file-p name)
          (with-parsed-tramp-file-name name v
            (with-no-warnings
              (cider-make-tramp-prefix v-method v-user v-host v-port))))))

Here is a random function from CIDER. The code is simple enough, the lisp is no problem. Immediately we see we're interacting from one extension to another, have to understand Emacs buffers, need to know how warnings are displayed, have to understand parsing as a domain, and appear to have a network involved. That is a lot of work to debug one function when something is misbehaving. Not an unreasonable situation, but nonetheless a barrier. Then on top of that I have to go look up what let* is and why it is presumably different from let. One more thing I don't want to do. Emacs lisp sucks.

EDITEDIT Tramp isn't an extension, it is part of core emacs. We live and learn.

EDITEDITEDIT Spoke too quickly, it looks like it is a GNU-supported extension. This is the sort of trivia that got me using Doom Emacs.

I’m fanatical about having and using the best tools. I take a great deal of pride in it.

I take great care with my VSCode extensions and their configuration. I likewise take great care with neovim and having it set up properly.

Modern Emacs Lisp is easily the best environment among my daily drivers for interacting with my editor in real time.

Of anything modern I only know Zed a little: Zed in theory might be better than Emacs.

Outside of maybe Zed, which I haven’t mastered, Emacs Lisp is bar nothing the best tool-making tool for serious hackers.

Feels odd to actually like elisp. :(

There are some surprises. And I do think common lisp has a lot of better parts. But, at the end of the day I find elisp fine for a scripting like language. And I love how accessible every line of elisp in my machine is.

With regards to lexical scope, yes elisp has that now, but it didn't for so long that a ton of existing code, including the standard library and editor interfaces was written without it, and there is a TON of global state.

I dream of combining wlroots and GNU Guile to make a graphic-first and multi-threaded by default Emacsen that does not aim to be source compatible with Emacs Lisp.

I'm actually writing some Emacs Lisp right now, because I want $FEATURE in Emacs. I've been away from Emacs Lisp for awhile in the land of Clojure and I'm reimporting certain things the way they are done there.

Libraries that help with that, even though the major underlying structure isn't immutable data structures make Emacs Lisp bearable are: s.el, ht.el, dash.el It would be great if there was namespacing and less global state pollution.

Of course if you want to integrate with the rest of the Emacs ecosystem and you want some libraries that help you out make things nice means learning a whole different ballgame. Like wanting to use the great transient.el. That's super stateful and based on eieio.el. (Although transient.el is relatively good about hiding that behind a good API surface.)

Overall, even though I wish it was based on a functional core and Clojure's immutable data structure, concurrency, namespacing and its great EDN reader, I just accept the pragmatism on the human scale that if I want a great text based interface that interacts with the rest of my text driven workflow Emacs is a good choice and Emacs Lisp is acceptable.

Its regex dialect is horrendous because of the sheer number of additional backslashes you end up having to use in string literals compared to other languages, e.g. "\\(a\\|b\\)" vs "(a|b)".

At least there's the "rx" DSL as an alternative.

I don't like Emacs Lisp a whole lot. It's probably my second least favorite Lisp to interact with. (Least favorite is Autolisp.) But it's a Lisp, it's gotten much better over the years, and it has lots of features that make automating what Emacs does really stinking convenient. Automating a task to smooth out a workflow usually takes maybe a page or two of Emacs Lisp, tops. And I can piece it together and try it out, live, in the editor session I'm doing my work in. Visual Studio Code has nothing comparable.

> But I believe there is a difference between making Emacs read mail or news or have a shell because you needed to in the 1970s and making Emacs browse web sites or act as an httpd because you can in the 2000s. I wonder if perhaps the people who want to fix all of EmacsLisp’s problems want to do so more for their own benefit – so it will be a better general-purpose development base and toolkit – than to make Emacs better for everyone. I wonder if they have lost sight of the primary application: the editor[5].

I actually get a lot of utility out of eww, it's not just a novelty for me. I can browse online documentation without a DM, or if I do have a DM, without moving my hand to the mouse. It's not just a novelty.

It is getting increasingly difficult to use; much like emacs the web has also transitioned from its original intention (hypertext documents) to a bloated app development platform and it's increasingly unfriendly and difficult to use with simple browsers. Even so, there are still websites worth visiting that are usable from trivial browsers as long as you avoid the many apps masquerading as webpages.

> but the former indicates a stigmatization of side-effecting in the Scheme community

Such poppycock. Clearly marking functions with side effects as such is not stigmatization, it's common sense. Don't take the sloppiness of other language cultures for the norm, although statistically it may well be. Too many people already think procedural object soup is how things should be.

So far as “APIs suck” I think about Guile scripting in the GIMP. I wouldn’t say “it sucks” but Guile seems nonsuperior to Lua, Visual Basic for Applications, and other languages built for embeddable scripting.

Is a MOP (like CLOS) going to bring substantial advantage to extensibility? My intuition says yes, but I can't test this hypothesis without thousands of plugin developers. Has any (meta) study even been done?

The only reason I immagine people might not be happy with elisp is when they reach a point and wish their emacs was their operating system - ie they wish elisp was a systems language - and dont want to learn C

I forgot where in the manual they explained that elisp was mostly influenced by maclisp (thus earlier than CL). Makes me curious how maclisp systems were designed now..

I know enough Elisp to assign a key combo to a kbd-macro fwiw