12 ms·

Why Does Elisp Suck

117 points by enthdegree 2y ago

Zambyte 2y ago
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.
- djaouen 2y ago
  Many have tried, but few have succeeded at creating an Emacs-replacement. Good luck!
  - pjmlp 2y ago
    I would say, that with Enrich Gamma at the steering wheel, and Microsoft's money, VSCode is succeeding pretty well.
    - guenthert 2y ago
      I'd think that VSCode eats into the 'market share' of Eclipse and the like, but I can't see it as replacement for Emacs at all.
      - pjmlp 2y ago
        Better look at the shape of Emacs market share evolution since VSCode exists. Turns out JavaScript is more appealing than Elisp, plus the graphical capabilities of having a browser engine.
    - School-Cotton 2y ago
      VS Code is nothing like emacs at all except in the most basic sense that they’re both text editors popular with programmers.
      - pjmlp 2y ago
        I am old enough to have used XEmacs when the paint was still drying.
- ducktective 2y ago
  Why wlroots? Isn't it better to target an abstraction api over the various GPU libraries (vulkan, metal etc)? And I would have asked about Guile too but that is another matter. I think LEM's approach is better here in utilizing SDL and common lisp. If they write an ELisp interpreter and somehow translate Emacs editor api so plugins would work in LEM too, that would be ideal.
  - 0cf8612b2e1e 2y ago
    Guile is the GNU extension language. Seems like the best candidate for an emacs replacement.
    - ducktective 2y ago
      Well, an Emacsen that hopes achieving the same degree of popularity as Emacs should be usable in Windows too. Last I checked, Guile had problems in Windows...
      - rbanffy 2y ago
        I wouldn’t consider running directly on Windows a hard requirement. You can run it under WSL[1|2] for instance, or bundle a very minimal WSL distribution that only runs your software.
        medstrom 2y ago
        It would also simplify the codebase, to scrap the native Windows support and outsource that responsibility to WSL.
    - School-Cotton 2y ago
      There was already a project to port emacs to run on guile. Guile supports both emacs lisp and scheme for this reason. The project seems to have run out of steam but it was mostly working at one point AFAIK.
  - vindarel 2y ago
- User23 2y ago
  On similar lines I've wondered about reimplementing the C parts of Emacs in Common Lisp. At that point Elisp would be a hosted language, letting you benefit from all the existing packages.
  - ReleaseCandidat 2y ago
    Lem is an Emacs using CL (also instead of Emacs Lisp): https://lem-project.github.io/ https://lem-project.github.io/
    - alt0_ 2y ago
      It is also graphical, and multi-threaded!
    - User23 2y ago
      I haven’t looked at lem in a while. I need to though. It and Nyxt are both really cool. Giving up the Elisp ecosystem will be hard though.
  - vindarel 2y ago
    That was the goal of CEDAR: https://gitlab.com/sasanidas/cedar https://gitlab.com/sasanidas/cedar (staled, too big of a project). But yeah, Lem!
- BeetleB 2y ago
  > that does not aim to be source compatible with Emacs Lisp. But then who would use it?
  - Zambyte 2y ago
    Me
HexDecOctBin 2y ago
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?
- tsimionescu 2y ago
  I think Elisp already implements a lot of things that CLOS would give you, like around method combinators (with defadvice, if I remember correctly). It's probably more ad-hoc, and you might want some extra customizations on top, but I'm not sure.
  - dokyun 2y ago
    Elisp already has a (partial, but for most purposes complete) implementation of CLOS as part of the cl-lib package.
nequo 2y ago
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!
- djaouen 2y ago
  That’s the charm of EmacsWiki. It really is community-edited!
  - noufalibrahim 2y ago
    It used to function as a semi permanent archive of all the babblings on #emacs on freenode. Those were the days...
- BeetleB 2y ago
  Fairly amusing that just today I was looking at some elisp code I wrote a few years ago. A comment I had inserted: ;; Also, I need the ~save-match-data~ because apparently ;; ~split-string~ messes up the match information. I spent hours ;; debugging this.
- agumonkey 2y ago
  Reminds me I often wished (and tried~) to make a purely functional regex lib in elisp
- sproutini 2y ago
  The problem with that statement isn't that some APIs use state but that the reason those APIs need state wasn't documented.
roenxi 2y ago
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 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.
- g15jv2dp 2y ago
  > This seems to be missing the elephant in the room - elisp doesn't suck, it is just a lisp. The article lists a few defaults of elisp that aren't shared by all lisps. What do you mean by this sentence?
benreesman 2y ago
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.
- throwaway48540 2y ago
  Do you have your configuration available somewhere? Would love to see some VSCode inspiration.
  - benreesman 2y ago
    I’m actually kind of a newb on sharing dots in the VSCode world, I auth with GitHub to get then on a new machine. Is there a way to publish that?
    - throwaway48540 2y ago
      You can open your settings using cmd/ctrl+comma and there is a button in top right corner that opens the JSON file itself.
      - benreesman 2y ago
        That procedure gives this opaque link: https://vscode.dev/editor/profile/github/e5b2f79ed7fbed47d95071509e643683 https://vscode.dev/editor/profile/github/e5b2f79ed7fbed47d95... I'm reticent to give you that garbage that I can't diff or know if it's worth anything. Life in the VSCode era.
- poulpy123 2y ago
  Why is zed better ? (Real question I don't know it)
medo-bear 2y ago
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
- lispm 2y ago
  I would think that people might wish Emacs Lisp would be a more capable application programming language. For example for an editor with such extensive capabilities, it would be useful that the language would provide preemptive scheduled threads and related constructs. On my old Lisp Machine, Zmacs ran in a multi-threaded Lisp roughly in the early 80s. Multiple Zmacs windows each had their own thread. Applications had their own thread. GC has its own threads. Even the mouse has its own thread. It still works that way. But you don't need a Lisp Machine OS with threaded Lisp for that. Many current implementations of Lisp support multi-threading. An example is SBCL, a natively compiled Common Lisp, which supports native threads on its platforms. Thus an editor written on top of SBCL could make use of that. IDEs of LispWorks and Allegro CL are also multi-threaded and they have their own implementations of Emacs, written in Common Lisp. Compare with GNU Emacs, where Emacs Lisp lacks this feature. Wouldn't you want an mail thread not block the rest of Lisp code? Some Lisp action in the REPL not to block the rest of Lisp code? Multi-threaded Lisp architectures are more complex. Emacs Lisp tried to be simple. But the stuff written in it long ago was outgrowing the provided simplicity. For a capable extension language it was "good enough" for a long time. For an "application development platform" it's not. Lack of multi-threading in Emacs Lisp and the GNU Emacs architecture is an example.
  - ducktective 2y ago
    >On Lisp Machine, Zmacs ran in a multi-threaded Lisp I wonder what the processing architecture of those Lisp machines were like. Did their "cpu"(?) had special circuitry for implementing lists, CAR and CDR? Was this multi-threaded-ness something built-in in hardware?
    - lispm 2y ago
      > Did their "cpu"(?) had special circuitry for implementing lists, CAR and CDR? It was implemented in Microcode on the CPU. > Was this multi-threaded-ness something built-in in hardware? Some. The process scheduler was written in Lisp. See for an early example on the MIT Lisp Machine: https://github.com/mietek/mit-cadr-system-software/blob/master/src/lispm2/proces.150 https://github.com/mietek/mit-cadr-system-software/blob/mast...
taeric 2y ago
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.
- lispm 2y ago
  I also find a lot of the user code well written. Helps to have various IDE support from the Editor and built-in documentation.
  - taeric 2y ago
    This actually reminds me that one thing that helps a lot, is to actively explore some of the code you are reliant on. I found elisp (and, well, lisp) a lot more intimidating before I started perusing code. The pragmatic approach so much lisp code goes for is refreshing and goes a long way to justify why some choices that may feel odd actually work really really well.
    - lispm 2y ago
      Yeah, that's really good advice.
dokyun 2y ago
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.
- _19qg 2y ago
  > 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. GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ... > Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does SLIME is mostly implemented in Emacs Lisp. A lot of other Lisp systems can locate all source code and all documentation. It's not so much a special feature of Emacs Lisp, but its development environment. It's also not necessary that the IDE and Lisp runs in the same process / same machine to be able to look up documentation and code. It may be convenient in GNU Emacs, but any such editor can provide such features for programming language implementations.
thayne 2y ago
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.
- TeMPOraL 2y ago
  > and there is a TON of global state. And that's usually good, because the whole point of Emacs is to make it easy to inspect and manipulate it. It's one case where information hiding and encapsulation - including lexical scope - get annoying very quickly.
  - zelphirkalt 2y ago
    It would probably require a lot more thought about how to make things so modifiable, yet avoid the global mutable state. Yet I think that is the work that will need to be done sooner or later, step by step, to keep the platform relevant.
sorry_i_lisp 2y ago
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.
deleted 2y ago
[deleted]
agumonkey 2y ago
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..
- crabbone 2y ago
  I never used MAC Lisp, but I read the documentation for it. CL is more similar to it than ELisp. It also didn't come particularly later. It's common to associate the date of ANSI CL standard publication with the "birth" of the language, however, the standard in this case was the attempt to unify and codify the existing language that was implemented in slightly different ways by various groups. You could even think about it as incorporating MAC Lisp as one of the components that went into standardization. Eg. the loop macro in CL is almost exact copy, whereas ELisp only has it in cl package. There are few more things like that. If memory serves, the idea for ELisp was to eventually become the "proper" Lisp for system programming. At the time, people used the word "Lisp" very liberally, in a way how we today might use "high-level programming language". And, in a way, Guile was supposed to become that, but as is the case with some such initiatives (eg. Hurd) it never gathered enough momentum to replace the predecessor that was "good enough" and was continuously kept afloat with more and more upgrades. As for the larger set of complaints about ELisp... it was good for a very long time, but it's getting old. There are many programming practices that are difficult to incorporate into the language. There are what we collectively came to believe to be programming anti-patterns that are encoded into the core of the language. And it's hard to do a proper face-lift because it will inevitably break a lot of old code. Also, doing such a face-lift you'd always be perplexed by the idea of what if a few years from now you could do an even better job of rewriting it into something even better? Knowing that one such change will put a ring on you, perhaps for the rest of your life, it's hard to make the step. Also, there are and have been many attempts of moving away from ELisp, and none really gained much traction among Emacs users. So, it's hard to imagine that the next such attempt will succeed. My fear in this regard is that one day, instead of evolving and replacing with something better, we'll be reduced to using junk like VSCode due to some underlying system aging out completely. Similar to what happened to Firefox when it lost its ability to house extensions. I pray this day never comes, but, in practical terms, it means that at some point the community of ELisp users needs to cut losses and embrace the loss of older libraries to move to a revamped ELisp2 or w/e it will be called.
frou_dh 2y ago
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.
- zelphirkalt 2y ago
  Exactly! When I saw that rx exists, I was delighted, that I don't actually have to write terrible regexes. Something like rx should exist in any serious lisp imo. Well, one should avoid regexes as much as possible, of course, but when you have to use them, rx is a great tool to have!
  - frou_dh 2y ago
    Personally I don't really have a problem with 'normal' regex. Learned it to a decent level, have gotten many years of value from that, reading and writing, generally no issues.
snickerbockers 2y ago
> 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.
- donio 2y ago
  > I actually get a lot of utility out of eww I do too. And the underlying shr rendering library is invaluable when so much of email traffic is text/html. A bunch of other stuff like mastodon.el and devdoc.el rely on it too. > It is getting increasingly difficult to use; In my experience it's not that much worse than it was 10 years ago. By the time eww came about the JS-less browsing ship has long sailed. The sort of stuff that was working back then still tends to work now. We lost some good sites like the BBC text-only mode but also gained some nice text proxies like 68k.news and brutalist.report.
bitwize 2y ago
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.
PaulHoule 2y ago
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.
mediumsmart 2y ago
I know enough Elisp to assign a key combo to a kbd-macro fwiw
zombot 2y ago
> 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.

117 points by enthdegree 2y ago

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.

djaouen 2y ago
Many have tried, but few have succeeded at creating an Emacs-replacement. Good luck!
- pjmlp 2y ago
  I would say, that with Enrich Gamma at the steering wheel, and Microsoft's money, VSCode is succeeding pretty well.
  - guenthert 2y ago
    I'd think that VSCode eats into the 'market share' of Eclipse and the like, but I can't see it as replacement for Emacs at all.
    - pjmlp 2y ago
      Better look at the shape of Emacs market share evolution since VSCode exists. Turns out JavaScript is more appealing than Elisp, plus the graphical capabilities of having a browser engine.
  - School-Cotton 2y ago
    VS Code is nothing like emacs at all except in the most basic sense that they’re both text editors popular with programmers.
    - pjmlp 2y ago
      I am old enough to have used XEmacs when the paint was still drying.
ducktective 2y ago
Why wlroots? Isn't it better to target an abstraction api over the various GPU libraries (vulkan, metal etc)? And I would have asked about Guile too but that is another matter. I think LEM's approach is better here in utilizing SDL and common lisp. If they write an ELisp interpreter and somehow translate Emacs editor api so plugins would work in LEM too, that would be ideal.
- 0cf8612b2e1e 2y ago
  Guile is the GNU extension language. Seems like the best candidate for an emacs replacement.
  - ducktective 2y ago
    Well, an Emacsen that hopes achieving the same degree of popularity as Emacs should be usable in Windows too. Last I checked, Guile had problems in Windows...
    - rbanffy 2y ago
      I wouldn’t consider running directly on Windows a hard requirement. You can run it under WSL[1|2] for instance, or bundle a very minimal WSL distribution that only runs your software.
      - medstrom 2y ago
        It would also simplify the codebase, to scrap the native Windows support and outsource that responsibility to WSL.
  - School-Cotton 2y ago
    There was already a project to port emacs to run on guile. Guile supports both emacs lisp and scheme for this reason. The project seems to have run out of steam but it was mostly working at one point AFAIK.
- vindarel 2y ago
User23 2y ago
On similar lines I've wondered about reimplementing the C parts of Emacs in Common Lisp. At that point Elisp would be a hosted language, letting you benefit from all the existing packages.
- ReleaseCandidat 2y ago
  Lem is an Emacs using CL (also instead of Emacs Lisp): https://lem-project.github.io/ https://lem-project.github.io/
  - alt0_ 2y ago
    It is also graphical, and multi-threaded!
  - User23 2y ago
    I haven’t looked at lem in a while. I need to though. It and Nyxt are both really cool. Giving up the Elisp ecosystem will be hard though.
- vindarel 2y ago
  That was the goal of CEDAR: https://gitlab.com/sasanidas/cedar https://gitlab.com/sasanidas/cedar (staled, too big of a project). But yeah, Lem!
BeetleB 2y ago
> that does not aim to be source compatible with Emacs Lisp. But then who would use it?
- Zambyte 2y ago
  Me

HexDecOctBin 2y ago

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?

tsimionescu 2y ago
I think Elisp already implements a lot of things that CLOS would give you, like around method combinators (with defadvice, if I remember correctly). It's probably more ad-hoc, and you might want some extra customizations on top, but I'm not sure.
- dokyun 2y ago
  Elisp already has a (partial, but for most purposes complete) implementation of CLOS as part of the cl-lib package.

nequo 2y ago

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!

djaouen 2y ago
That’s the charm of EmacsWiki. It really is community-edited!
- noufalibrahim 2y ago
  It used to function as a semi permanent archive of all the babblings on #emacs on freenode. Those were the days...
BeetleB 2y ago
Fairly amusing that just today I was looking at some elisp code I wrote a few years ago. A comment I had inserted: ;; Also, I need the ~save-match-data~ because apparently ;; ~split-string~ messes up the match information. I spent hours ;; debugging this.
agumonkey 2y ago
Reminds me I often wished (and tried~) to make a purely functional regex lib in elisp
sproutini 2y ago
The problem with that statement isn't that some APIs use state but that the reason those APIs need state wasn't documented.

roenxi 2y ago

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

g15jv2dp 2y ago
> This seems to be missing the elephant in the room - elisp doesn't suck, it is just a lisp. The article lists a few defaults of elisp that aren't shared by all lisps. What do you mean by this sentence?

benreesman 2y ago

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.

throwaway48540 2y ago
Do you have your configuration available somewhere? Would love to see some VSCode inspiration.
- benreesman 2y ago
  I’m actually kind of a newb on sharing dots in the VSCode world, I auth with GitHub to get then on a new machine. Is there a way to publish that?
  - throwaway48540 2y ago
    You can open your settings using cmd/ctrl+comma and there is a button in top right corner that opens the JSON file itself.
    - benreesman 2y ago
      That procedure gives this opaque link: https://vscode.dev/editor/profile/github/e5b2f79ed7fbed47d95071509e643683 https://vscode.dev/editor/profile/github/e5b2f79ed7fbed47d95... I'm reticent to give you that garbage that I can't diff or know if it's worth anything. Life in the VSCode era.
poulpy123 2y ago
Why is zed better ? (Real question I don't know it)

medo-bear 2y ago

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

lispm 2y ago
I would think that people might wish Emacs Lisp would be a more capable application programming language. For example for an editor with such extensive capabilities, it would be useful that the language would provide preemptive scheduled threads and related constructs. On my old Lisp Machine, Zmacs ran in a multi-threaded Lisp roughly in the early 80s. Multiple Zmacs windows each had their own thread. Applications had their own thread. GC has its own threads. Even the mouse has its own thread. It still works that way. But you don't need a Lisp Machine OS with threaded Lisp for that. Many current implementations of Lisp support multi-threading. An example is SBCL, a natively compiled Common Lisp, which supports native threads on its platforms. Thus an editor written on top of SBCL could make use of that. IDEs of LispWorks and Allegro CL are also multi-threaded and they have their own implementations of Emacs, written in Common Lisp. Compare with GNU Emacs, where Emacs Lisp lacks this feature. Wouldn't you want an mail thread not block the rest of Lisp code? Some Lisp action in the REPL not to block the rest of Lisp code? Multi-threaded Lisp architectures are more complex. Emacs Lisp tried to be simple. But the stuff written in it long ago was outgrowing the provided simplicity. For a capable extension language it was "good enough" for a long time. For an "application development platform" it's not. Lack of multi-threading in Emacs Lisp and the GNU Emacs architecture is an example.
- ducktective 2y ago
  >On Lisp Machine, Zmacs ran in a multi-threaded Lisp I wonder what the processing architecture of those Lisp machines were like. Did their "cpu"(?) had special circuitry for implementing lists, CAR and CDR? Was this multi-threaded-ness something built-in in hardware?
  - lispm 2y ago
    > Did their "cpu"(?) had special circuitry for implementing lists, CAR and CDR? It was implemented in Microcode on the CPU. > Was this multi-threaded-ness something built-in in hardware? Some. The process scheduler was written in Lisp. See for an early example on the MIT Lisp Machine: https://github.com/mietek/mit-cadr-system-software/blob/master/src/lispm2/proces.150 https://github.com/mietek/mit-cadr-system-software/blob/mast...

taeric 2y ago

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.

lispm 2y ago
I also find a lot of the user code well written. Helps to have various IDE support from the Editor and built-in documentation.
- taeric 2y ago
  This actually reminds me that one thing that helps a lot, is to actively explore some of the code you are reliant on. I found elisp (and, well, lisp) a lot more intimidating before I started perusing code. The pragmatic approach so much lisp code goes for is refreshing and goes a long way to justify why some choices that may feel odd actually work really really well.
  - lispm 2y ago
    Yeah, that's really good advice.

dokyun 2y ago

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.

_19qg 2y ago
> 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. GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ... > Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does SLIME is mostly implemented in Emacs Lisp. A lot of other Lisp systems can locate all source code and all documentation. It's not so much a special feature of Emacs Lisp, but its development environment. It's also not necessary that the IDE and Lisp runs in the same process / same machine to be able to look up documentation and code. It may be convenient in GNU Emacs, but any such editor can provide such features for programming language implementations.

thayne 2y ago

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.

TeMPOraL 2y ago
> and there is a TON of global state. And that's usually good, because the whole point of Emacs is to make it easy to inspect and manipulate it. It's one case where information hiding and encapsulation - including lexical scope - get annoying very quickly.
- zelphirkalt 2y ago
  It would probably require a lot more thought about how to make things so modifiable, yet avoid the global mutable state. Yet I think that is the work that will need to be done sooner or later, step by step, to keep the platform relevant.

sorry_i_lisp 2y ago

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.

deleted 2y ago

[deleted]

agumonkey 2y ago

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

crabbone 2y ago
I never used MAC Lisp, but I read the documentation for it. CL is more similar to it than ELisp. It also didn't come particularly later. It's common to associate the date of ANSI CL standard publication with the "birth" of the language, however, the standard in this case was the attempt to unify and codify the existing language that was implemented in slightly different ways by various groups. You could even think about it as incorporating MAC Lisp as one of the components that went into standardization. Eg. the loop macro in CL is almost exact copy, whereas ELisp only has it in cl package. There are few more things like that. If memory serves, the idea for ELisp was to eventually become the "proper" Lisp for system programming. At the time, people used the word "Lisp" very liberally, in a way how we today might use "high-level programming language". And, in a way, Guile was supposed to become that, but as is the case with some such initiatives (eg. Hurd) it never gathered enough momentum to replace the predecessor that was "good enough" and was continuously kept afloat with more and more upgrades. As for the larger set of complaints about ELisp... it was good for a very long time, but it's getting old. There are many programming practices that are difficult to incorporate into the language. There are what we collectively came to believe to be programming anti-patterns that are encoded into the core of the language. And it's hard to do a proper face-lift because it will inevitably break a lot of old code. Also, doing such a face-lift you'd always be perplexed by the idea of what if a few years from now you could do an even better job of rewriting it into something even better? Knowing that one such change will put a ring on you, perhaps for the rest of your life, it's hard to make the step. Also, there are and have been many attempts of moving away from ELisp, and none really gained much traction among Emacs users. So, it's hard to imagine that the next such attempt will succeed. My fear in this regard is that one day, instead of evolving and replacing with something better, we'll be reduced to using junk like VSCode due to some underlying system aging out completely. Similar to what happened to Firefox when it lost its ability to house extensions. I pray this day never comes, but, in practical terms, it means that at some point the community of ELisp users needs to cut losses and embrace the loss of older libraries to move to a revamped ELisp2 or w/e it will be called.

frou_dh 2y ago

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.

zelphirkalt 2y ago
Exactly! When I saw that rx exists, I was delighted, that I don't actually have to write terrible regexes. Something like rx should exist in any serious lisp imo. Well, one should avoid regexes as much as possible, of course, but when you have to use them, rx is a great tool to have!
- frou_dh 2y ago
  Personally I don't really have a problem with 'normal' regex. Learned it to a decent level, have gotten many years of value from that, reading and writing, generally no issues.

snickerbockers 2y ago

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

donio 2y ago
> I actually get a lot of utility out of eww I do too. And the underlying shr rendering library is invaluable when so much of email traffic is text/html. A bunch of other stuff like mastodon.el and devdoc.el rely on it too. > It is getting increasingly difficult to use; In my experience it's not that much worse than it was 10 years ago. By the time eww came about the JS-less browsing ship has long sailed. The sort of stuff that was working back then still tends to work now. We lost some good sites like the BBC text-only mode but also gained some nice text proxies like 68k.news and brutalist.report.

bitwize 2y ago

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.

PaulHoule 2y ago

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.

mediumsmart 2y ago

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

zombot 2y ago

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