<story><title>Why Does Elisp Suck</title><url>https://www.emacswiki.org/emacs/WhyDoesElispSuck</url></story><parent_chain><item><author>dokyun</author><text>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 &amp;quot;Emacs Lisp basically isn&amp;#x27;t [some other language]&amp;quot;, or misconceptions about the philosophy of how the system is designed.&lt;p&gt;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.&lt;p&gt;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 &amp;#x2F;understanding&amp;#x2F; 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.&lt;p&gt;Certain points like the fact that Emacs isn&amp;#x27;t multithreaded are thrown around by people who don&amp;#x27;t have the intuition that multithreading isn&amp;#x27;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.&lt;p&gt;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.</text></item></parent_chain><comment><author>zelphirkalt</author><text>&amp;gt; Certain points like the fact that Emacs isn&amp;#x27;t multithreaded are thrown around by people who don&amp;#x27;t have the intuition that multithreading isn&amp;#x27;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.&lt;p&gt;I disagree with this point. Emacs does not have a useful process model, or at least it cannot be used to the full extend, because of shared global mutable state. This is exactly the issue, not a practical thing. If it were not for all the usage of mutable (and mutated) global state, Emacs could actually benefit from running many things concurrently, without annoying users with blocking behavior.&lt;p&gt;This is of course a huge task to refactor Emacs like that. I can only hope, that some day we will get there, because I see it as one fatal flaw, that could over time kill Emacs. Yes, Emacs as it is is super useful, but more and more things come up, that will be better off running concurrently and in parallel. Just to name a few: Package compilation, waiting for LSP stuff, anything that waits for network, like tramp, running source blocks in org-mode (org-babel), syntax highlighting of big files, magit stuff like rendering huge diffs in a magit status buffer ...&lt;p&gt;All of those things could benefit from being able to use multiple cores and improve Emacs&amp;#x27; snappiness and speed. All of these come before even changing anything about elisp the language.</text></comment>
<story><title>Why Does Elisp Suck</title><url>https://www.emacswiki.org/emacs/WhyDoesElispSuck</url></story><parent_chain><item><author>dokyun</author><text>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 &amp;quot;Emacs Lisp basically isn&amp;#x27;t [some other language]&amp;quot;, or misconceptions about the philosophy of how the system is designed.&lt;p&gt;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.&lt;p&gt;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 &amp;#x2F;understanding&amp;#x2F; 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.&lt;p&gt;Certain points like the fact that Emacs isn&amp;#x27;t multithreaded are thrown around by people who don&amp;#x27;t have the intuition that multithreading isn&amp;#x27;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.&lt;p&gt;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.</text></item></parent_chain><comment><author>lispm</author><text>&amp;gt; Certain points like the fact that Emacs isn&amp;#x27;t multithreaded are thrown around by people who don&amp;#x27;t have the intuition that multithreading isn&amp;#x27;t the right thing for a lot of applications.&lt;p&gt;GNU Emacs has a lot of applications where it is the right thing. It&amp;#x27;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, ...&lt;p&gt;&amp;gt; Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does&lt;p&gt;SLIME is mostly implemented in Emacs Lisp. A lot of other Lisp systems can locate all source code and all documentation. It&amp;#x27;s not so much a special feature of Emacs Lisp, but its development environment. It&amp;#x27;s also not necessary that the IDE and Lisp runs in the same process &amp;#x2F; 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.</text></comment>