Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Emacs Lisp on Guile

emacsninja.com

Post reply on HN
Print view View original

21–30 of 66 posts

Re: State of Emacs Lisp on Guile

#21

Post by fredmorcos »

nine_k wrote: post #20
na85 wrote: post #12

Earlier quoted context omitted.

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.

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.

Re: State of Emacs Lisp on Guile

#22

Post by logicchains »

nine_k wrote: post #20
na85 wrote: post #12

Earlier quoted context omitted.

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.

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

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

Re: State of Emacs Lisp on Guile

#23

Post by tines »

throwaway894345 wrote: post #19
tines wrote: post #17

Earlier quoted context omitted.

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

Re: State of Emacs Lisp on Guile

#24

Post by fizixer »

nine_k wrote: post #20
na85 wrote: post #12

Earlier quoted context omitted.

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.

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

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

Re: State of Emacs Lisp on Guile

#25

Post by nine_k »

logicchains wrote: post #22
nine_k wrote: post #20

Earlier quoted context omitted.

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

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.

Re: State of Emacs Lisp on Guile

#26

Post by teataster »

na85 wrote: post #12
melling wrote: post #5

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…

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.

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.

Re: State of Emacs Lisp on Guile

#27

Post by metroholografix »

dig1 wrote: post #9

Honest question: what are the benefits of Guile Emacs in 2020 and after? Guile speed? I'm aware Guile (especially) later versions got really good VM and general optimizations, but with recent work in gccemacs [1] and having complete gcc optimization engine under the belt, can these two be even compared? Also, gccemacs showed you get visible speedups in some use cases only. Have everything under Guile umbrella? Rememb…

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.

Re: State of Emacs Lisp on Guile

#28

Post by onetom »

nine_k wrote: post #20
na85 wrote: post #12

Earlier quoted context omitted.

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.

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

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

Re: State of Emacs Lisp on Guile

#29

Post by metroholografix »

melling wrote: post #5

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…

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.

Re: State of Emacs Lisp on Guile

#30

Post by teataster »

metroholografix wrote: post #27
dig1 wrote: post #9

Honest question: what are the benefits of Guile Emacs in 2020 and after? Guile speed? I'm aware Guile (especially) later versions got really good VM and general optimizations, but with recent work in gccemacs [1] and having complete gcc optimization engine under the belt, can these two be even compared? Also, gccemacs showed you get visible speedups in some use cases only. Have everything under Guile umbrella? Rememb…

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 cu…

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.

Post reply on HN