Hacker News Reader

Comment by melling | Hacker News Reader

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

View on HN

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.

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

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.

I'm not familiar with the vim world. How different is the neovim API? Do the developers maintain two versions of their plugins?

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.

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 :-\

This comparison is laughable and ignorant.

Anecdata: I switched from VSCode to Emacs because VSCode kept freezing, have not once regretted that decision.

This is especially funny given ES6's allegedly superior concurrency story.

30 years in development do help avoid some pitfalls, though.

VSCode is a M$ initiative. Give it a couple years.

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-spacem...), which itself is written in ClojureScript, which is live-reloadable...

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)

Why a mere WM; I can imagine booting into VS as some people boot into Emacs.

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.

The language itself I don't really have a problem with, but it's slow.

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.

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

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.

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.

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

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

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

That is because op didn't run it in Emacs. Guile-emacs uses the same Emacs c functions that Emacs elisp does, and running the Emacs tests against guiles elisp-without Emacs is like taking away a huge part of the standard functionality and expecting things to run.

The points it makes about speed are not wrong, but that the author fails to understand even the most basic relations between Guile-emacs and guile-elisp makes it hard for me to take it seriously.

Reply on news.ycombinator.com