Hacker News Reader

Comment by na85 | Hacker News Reader

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.

View on HN

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

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.

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.

Reply on news.ycombinator.com