6 ms·

Guile is almost 30 years old. It’s GNU’s Scheme implementation. People wanted to replace the nonstandard Emacs Lisp with Scheme but since so much code was writ

Guile is almost 30 years old. It’s GNU’s Scheme implementation. People wanted to replace the nonstandard Emacs Lisp with Scheme but since so much code was written in elisp, they didn’t want to throw it out. At this point someone should abstract out the Emacs definition so others could build it with Scheme or Clojure. Emacs is basically a Lisp interpreter. They wrote the parts that needed to be fast in C and the rest is elisp. 45 years ago Emacs needed to be built in C. Today the entire thing could be built with a standard Lisp. I suppose if someone wrote an Emacs in Scheme, the projects could converge once Guile is integrated into Emacs

na85 6y ago
I sometimes feel that someone needs to declare "elisp bankruptcy" in the same vein as one declares inbox bankruptcy, accept that implementing all of elisp in another superior lisp is too much work, write a better emacs-alike from the ground up in a proper, performant lisp, and let the package authors do the work of porting their packages.
- tines 6y ago
  > let the package authors do the work of porting their packages. Unfortunately that will never happen, and since packages are the reason anyone uses anything, no one will use the newmacs. If there were a translation layer for backwards compatibility then that could work, but the one with more packages wins, so I don't think it could work without it.
  - throwaway894345 6y ago
    Neovim is getting good traction in the vim space. It turns out that developers are also annoyed by these issues on legacy platforms and are motivated to support the new system.
    - tines 6y ago
      I'm not familiar with the vim world. How different is the neovim API? Do the developers maintain two versions of their plugins?
      - throwaway894345 6y ago
        I'm not that familiar with the details. My understanding is that neovim at least mostly supports the vim language, but also offers other APIs (not clear about whether these APIs are extensions of the VIM language or altogether different) that allow developers to work around common VIM issues. My crude impression is that developers actively prefer to interface with the new APIs, and many packages aren't even backwards compatible with VIM.
- nine_k 6y ago
  This has happened, and the result is VSCode. Of course, ES6 is less powerful than Scheme, but the speed and the mindshare outweighed the homoiconicity and the macros :-\
  - fredmorcos 6y ago
    This comparison is laughable and ignorant.
  - logicchains 6y ago
    Anecdata: I switched from VSCode to Emacs because VSCode kept freezing, have not once regretted that decision.
    - nine_k 6y ago
      This is especially funny given ES6's allegedly superior concurrency story. 30 years in development do help avoid some pitfalls, though.
  - fizixer 6y ago
    VSCode is a M$ initiative. Give it a couple years.
  - onetom 6y ago
    I got the feeling that Atom might be a better analogy. For example, you can get a Spacemacs like environment if you use the Proton extension (https://discuss.atom.io/t/announce-proton-vim-focused-spacemacs-inspired-way-of-using-atom-help-wanted/23263 https://discuss.atom.io/t/announce-proton-vim-focused-spacem...), which itself is written in ClojureScript, which is live-reloadable...
  - ssivark 6y ago
    Speed and mindshare don’t make up for a lack of flexibility and power. No one’s gonna be running a window manager based on VS Code, and that should tell you something (see EXWM)
    - 6y ago
- teataster 6y ago
  Honest question. What's wrong with elisp? I have never been limited by it. Granted, it's probably the worst lisp. But it works just fine for it's intended use. It could be argued that is one of the most used lisps. As for porting packages, some are old and will never get ported and packages are the spice of emacs.
  - na85 6y ago
    The language itself I don't really have a problem with, but it's slow.
davexunit 6y ago
It's true that Guile is a Scheme implementation, but it is also a platform to host any other language. The Guile-Emacs project wasn't about removing Elisp, it was about making Elisp run on the Guile VM.
- melling 6y ago
  Yes, that’s what I meant. They don’t want to throw away the Elisp but they want to support a Scheme. Someday in the far far future long after Scheme is supported and millions of lines is rewritten in Scheme, I could imagine dropping support for Elisp. Then Emacs will be nothing more than a large Scheme program that could run on any implementation of Scheme
  - alvatar 6y ago
    I think it's easier to port everything elisp to Scheme (with some help by automation perhaps), than having an Emacs implementation in a Scheme that runs in all implementation of Scheme. I've worked many years in Scheme and the differences between compilers and interpreters are too large, especially when it comes to low-level functionality necessary for good performance.
metroholografix 6y ago
You are assuming many things that are simply not true. There is no goal or will to integrate Guile in Emacs. It was a failed experiment taken up by volunteers outside of the core Emacs development team. Most of the value in the Emacs ecosystem lies in Emacs Lisp and not in an "abstracted out" Emacs definition. Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and guess what, all of them went nowhere. Because they were missing the point, just like you do.
- pmoriarty 6y ago
  "Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and guess what, all of them went nowhere." If they were: 1 - Lispy 2 - Faster 3 - Fully compatible with existing eLisp packages. I think people would switch. Guile Emacs is all of those except (at this point) faster.. when I tried it, it was unfortunately way slower. If the speed could be improved a lot and the remaining bugs ironed out, it would be a very strong contender.
  - metroholografix 6y ago
    > Guile Emacs is all of those except (at this point) faster. Guile Emacs is not at all compatible with Emacs Lisp, it only implements a tiny subset of Emacs Lisp. It's right there in OP's article. So the only thing it has going for it is being .. Lispy. Not enough.
    - pmoriarty 6y ago
      In my own testing from Nov 2017, I got GUI Emacs to run.. it was slow, but it ran. Vanilla GUI Emacs runs a non-trivial amount of eLisp code, so at least then with the version of Emacs I used (24.4.50) the compatibility situation could not have been dire than what the OP reported. Also, you have to bear in mind that Guile Emacs was the work of one single (very talented) person over a single summer. If there was actually a team of people working on it, I expect a lot more progress towards compatibility could be made. Here is a list of outstanding items that still need to be worked on Guile Emacs: https://www.emacswiki.org/emacs/GuileEmacsTodo https://www.emacswiki.org/emacs/GuileEmacsTodo

na85 6y ago

I sometimes feel that someone needs to declare "elisp bankruptcy" in the same vein as one declares inbox bankruptcy, accept that implementing all of elisp in another superior lisp is too much work, write a better emacs-alike from the ground up in a proper, performant lisp, and let the package authors do the work of porting their packages.

tines 6y ago
> let the package authors do the work of porting their packages. Unfortunately that will never happen, and since packages are the reason anyone uses anything, no one will use the newmacs. If there were a translation layer for backwards compatibility then that could work, but the one with more packages wins, so I don't think it could work without it.
- throwaway894345 6y ago
  Neovim is getting good traction in the vim space. It turns out that developers are also annoyed by these issues on legacy platforms and are motivated to support the new system.
  - tines 6y ago
    I'm not familiar with the vim world. How different is the neovim API? Do the developers maintain two versions of their plugins?
    - throwaway894345 6y ago
      I'm not that familiar with the details. My understanding is that neovim at least mostly supports the vim language, but also offers other APIs (not clear about whether these APIs are extensions of the VIM language or altogether different) that allow developers to work around common VIM issues. My crude impression is that developers actively prefer to interface with the new APIs, and many packages aren't even backwards compatible with VIM.
nine_k 6y ago
This has happened, and the result is VSCode. Of course, ES6 is less powerful than Scheme, but the speed and the mindshare outweighed the homoiconicity and the macros :-\
- fredmorcos 6y ago
  This comparison is laughable and ignorant.
- logicchains 6y ago
  Anecdata: I switched from VSCode to Emacs because VSCode kept freezing, have not once regretted that decision.
  - nine_k 6y ago
    This is especially funny given ES6's allegedly superior concurrency story. 30 years in development do help avoid some pitfalls, though.
- fizixer 6y ago
  VSCode is a M$ initiative. Give it a couple years.
- onetom 6y ago
  I got the feeling that Atom might be a better analogy. For example, you can get a Spacemacs like environment if you use the Proton extension (https://discuss.atom.io/t/announce-proton-vim-focused-spacemacs-inspired-way-of-using-atom-help-wanted/23263 https://discuss.atom.io/t/announce-proton-vim-focused-spacem...), which itself is written in ClojureScript, which is live-reloadable...
- ssivark 6y ago
  Speed and mindshare don’t make up for a lack of flexibility and power. No one’s gonna be running a window manager based on VS Code, and that should tell you something (see EXWM)
  - 6y ago
teataster 6y ago
Honest question. What's wrong with elisp? I have never been limited by it. Granted, it's probably the worst lisp. But it works just fine for it's intended use. It could be argued that is one of the most used lisps. As for porting packages, some are old and will never get ported and packages are the spice of emacs.
- na85 6y ago
  The language itself I don't really have a problem with, but it's slow.

davexunit 6y ago

It's true that Guile is a Scheme implementation, but it is also a platform to host any other language. The Guile-Emacs project wasn't about removing Elisp, it was about making Elisp run on the Guile VM.

melling 6y ago
Yes, that’s what I meant. They don’t want to throw away the Elisp but they want to support a Scheme. Someday in the far far future long after Scheme is supported and millions of lines is rewritten in Scheme, I could imagine dropping support for Elisp. Then Emacs will be nothing more than a large Scheme program that could run on any implementation of Scheme
- alvatar 6y ago
  I think it's easier to port everything elisp to Scheme (with some help by automation perhaps), than having an Emacs implementation in a Scheme that runs in all implementation of Scheme. I've worked many years in Scheme and the differences between compilers and interpreters are too large, especially when it comes to low-level functionality necessary for good performance.

metroholografix 6y ago

You are assuming many things that are simply not true. There is no goal or will to integrate Guile in Emacs. It was a failed experiment taken up by volunteers outside of the core Emacs development team. Most of the value in the Emacs ecosystem lies in Emacs Lisp and not in an "abstracted out" Emacs definition. Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and guess what, all of them went nowhere. Because they were missing the point, just like you do.

pmoriarty 6y ago
"Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and guess what, all of them went nowhere." If they were: 1 - Lispy 2 - Faster 3 - Fully compatible with existing eLisp packages. I think people would switch. Guile Emacs is all of those except (at this point) faster.. when I tried it, it was unfortunately way slower. If the speed could be improved a lot and the remaining bugs ironed out, it would be a very strong contender.
- metroholografix 6y ago
  > Guile Emacs is all of those except (at this point) faster. Guile Emacs is not at all compatible with Emacs Lisp, it only implements a tiny subset of Emacs Lisp. It's right there in OP's article. So the only thing it has going for it is being .. Lispy. Not enough.
  - pmoriarty 6y ago
    In my own testing from Nov 2017, I got GUI Emacs to run.. it was slow, but it ran. Vanilla GUI Emacs runs a non-trivial amount of eLisp code, so at least then with the version of Emacs I used (24.4.50) the compatibility situation could not have been dire than what the OP reported. Also, you have to bear in mind that Guile Emacs was the work of one single (very talented) person over a single summer. If there was actually a team of people working on it, I expect a lot more progress towards compatibility could be made. Here is a list of outstanding items that still need to be worked on Guile Emacs: https://www.emacswiki.org/emacs/GuileEmacsTodo https://www.emacswiki.org/emacs/GuileEmacsTodo