3 ms·

The are no benefits. In fact, what few folks consider benefits -be able to extend Emacs with JavaScript or Scheme- I think are major issues that have the potent

The are no benefits. In fact, what few folks consider benefits -be able to extend Emacs with JavaScript or Scheme- I think are major issues that have the potential to destroy Emacs. Emacs Lisp fits the problem domain like a glove. Someone in this thread called it 'the worst Lisp' but that's a mischaracterization. It's actually a good, practical, Lisp and far from the worst. In short, there is enormous value in the current Emacs Lisp ecosystem, and every heavy Emacs user knows it. Guile doesn't really have much to offer, given its terrible performance, lack of interest from developers (and some would say users), platform-compatibility issues and strong potential for diluting a very valuable, very cohesive ecosystem. It is a project that is slowly languishing while Emacs Lisp is slowly but surely getting better.

teataster 6y ago
I called it "probably" the worst lisp. I enjoy very much working with elisp, and almost 100% agree with your characterization of it. But it is a fairly clunky language with all it's let, letstar, letdash, letstardash... You know what I mean. I am no elisp history expert, but I believe that is due to it's age and how easy it is to extend. And just to reiterate, I have never felt limited by it, I really like it, I would not change it and it solves the domain problem just fine.
- metroholografix 6y ago
  There are Lisps out there that are actually bad. For example, I find every Clojure-inspired neoLisp to be bad. Or something like newLISP. These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. On the other hand languages like TXR Lisp and Emacs Lisp have made certain compromises in order to better fit their problem domains, but are fully aligned with the core ideas of Lisp as defined through its historical evolution. I also don't see let, letstar, etc as clunky but I've also been using them for more than a decade (and am firmly in the Lisp Machine Lisp -> Common Lisp camp).
  - teataster 6y ago
    You seem to be a more experienced lisper than me (I mostly do elisp scripts and a bit of Clojure) and I have learned a bit from your answer. Thanks.
  - progre 6y ago
    > These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. So can you elaborate on what those design errors might be? And what exactly is the "concept of lisp"?
    - metroholografix 6y ago
      One example: https://www.gnu.org/software/emacs/manual/html_node/elisp/Cons-Cells.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Co... The concept of Lisp through its historic evolution refers to the set of ideas and implementation details that allows one to read a book about Lisp written 40 years ago and apply the same concepts through a language called Lisp today without any -major- changes. If that's not possible or involves substantial programming logic rewriting, the language should not be viewed as Lisp.
davexunit 6y ago
The benefit is not in extending Emacs with different languages (though there would be nothing stopping people from doing so since Guile is a multi-language platform, like Racket) but in separating the concerns of text editing software from programming language implementation. Emacs is great at the text editing part, but has to reinvent the wheel over and over when it comes to the compiler/VM part. It is wrong to say that Guile has terrible performance. Guile Scheme is more performant than the standard implementations of elisp, python, ruby, and other so-called scripting languages. Each major release of Guile has had significant performance improvements, most recently a JIT compiler. It is true that the elisp implementation on Guile is slow, but that's a reflection of the project being a prototype and not production-ready. It could be fast if there was interest in developing it, but there isn't so it's just another interesting but dead project.

teataster 6y ago

I called it "probably" the worst lisp. I enjoy very much working with elisp, and almost 100% agree with your characterization of it. But it is a fairly clunky language with all it's let, letstar, letdash, letstardash... You know what I mean. I am no elisp history expert, but I believe that is due to it's age and how easy it is to extend. And just to reiterate, I have never felt limited by it, I really like it, I would not change it and it solves the domain problem just fine.

metroholografix 6y ago
There are Lisps out there that are actually bad. For example, I find every Clojure-inspired neoLisp to be bad. Or something like newLISP. These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. On the other hand languages like TXR Lisp and Emacs Lisp have made certain compromises in order to better fit their problem domains, but are fully aligned with the core ideas of Lisp as defined through its historical evolution. I also don't see let, letstar, etc as clunky but I've also been using them for more than a decade (and am firmly in the Lisp Machine Lisp -> Common Lisp camp).
- teataster 6y ago
  You seem to be a more experienced lisper than me (I mostly do elisp scripts and a bit of Clojure) and I have learned a bit from your answer. Thanks.
- progre 6y ago
  > These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. So can you elaborate on what those design errors might be? And what exactly is the "concept of lisp"?
  - metroholografix 6y ago
    One example: https://www.gnu.org/software/emacs/manual/html_node/elisp/Cons-Cells.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Co... The concept of Lisp through its historic evolution refers to the set of ideas and implementation details that allows one to read a book about Lisp written 40 years ago and apply the same concepts through a language called Lisp today without any -major- changes. If that's not possible or involves substantial programming logic rewriting, the language should not be viewed as Lisp.

davexunit 6y ago

The benefit is not in extending Emacs with different languages (though there would be nothing stopping people from doing so since Guile is a multi-language platform, like Racket) but in separating the concerns of text editing software from programming language implementation. Emacs is great at the text editing part, but has to reinvent the wheel over and over when it comes to the compiler/VM part. It is wrong to say that Guile has terrible performance. Guile Scheme is more performant than the standard implementations of elisp, python, ruby, and other so-called scripting languages. Each major release of Guile has had significant performance improvements, most recently a JIT compiler. It is true that the elisp implementation on Guile is slow, but that's a reflection of the project being a prototype and not production-ready. It could be fast if there was interest in developing it, but there isn't so it's just another interesting but dead project.