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

61–66 of 66 posts

Re: State of Emacs Lisp on Guile

#61

Post by nonbirithm »

heintje_ghulam wrote: post #53
pmoriarty wrote: post #45

Earlier quoted context omitted.

I would firmly oppose switching the entirety of the Emacs ecosystem to JS, Lua, Rust or any other non-Lispy language, but that's not what we're talking about here. If an occasionaly JS or Lua package becomes available through Guile, what's the harm? Anyway, I don't see this as the primary benefit of Guile Emacs.. the rest benefits that Andy Wingo mentions are much more interesting and valuable to me, not JS/Lua compa…

The problem with your point of view is that if it came to pass, then anyone who wanted to work on Emacs packages would have to learn multiple programming languages when before they only needed one, Elisp. Having packages in multiple languages hurts the ability of people to help contribute to each others' work (especially if they don't have time or space to learn multiple languages).

Agreed, and I was disappointed about xi-editor's approach of using an RPC so any language can be used for extension. For all its issues at least elisp is ubiquitous, and contributes to feature discoverability.

Re: State of Emacs Lisp on Guile

#62

Post by shanemhansen »

metroholografix wrote: post #39
pmoriarty wrote: post #36

Earlier quoted context omitted.

"what are the benefits of Guile Emacs in 2020 and after?" Here is what Andy Wingo had to say on the subject[1]: Guile can implement Emacs Lisp better than Emacs can. We can compile Emacs Lisp to Guile's VM, and make C shims to present a suitably compatible C interface to the rest of Emacs' C primitives. No one will notice! Except that after a switch, Emacs would be faster, more powerful, and have the ability to acces…

I think it's safe to say at this point -more than 10 years later- that Andy Wingo was very optimistic. Absolutely nothing of what he described in that email materialized. And it's no wonder it didn't, since a lot of it is simply wishful thinking. In addition, he didn't address the fact that there are political and not technical reasons behind the absence of certain features (e.g. FFI). They could be done today, witho…

FWIW I think you could say FFI is possible. I've written a Golang module for emacs and build using -buildmode=c-shared and loaded it into emacs. I think for generic FFI you could probably wrap some sort of libffi.so using elisp.

Re: State of Emacs Lisp on Guile

#63

Post by metroholografix »

shanemhansen wrote: post #62
metroholografix wrote: post #39

Earlier quoted context omitted.

I think it's safe to say at this point -more than 10 years later- that Andy Wingo was very optimistic. Absolutely nothing of what he described in that email materialized. And it's no wonder it didn't, since a lot of it is simply wishful thinking. In addition, he didn't address the fact that there are political and not technical reasons behind the absence of certain features (e.g. FFI). They could be done today, witho…

FWIW I think you could say FFI is possible. I've written a Golang module for emacs and build using -buildmode=c-shared and loaded it into emacs. I think for generic FFI you could probably wrap some sort of libffi.so using elisp.

There exist multiple Emacs FFI implementations [1], [2]. None of them are included in Emacs though and that's the main issue. For something like FFI to be maximally useful, you do want it to be part of Emacs and not an additional -compiled- add-on.

The problem is not technical, but political. For years, RMS has opposed an Emacs FFI due to his belief that it could be used to subvert Emacs goals by making it possible to do proprietary extensions.

[1] https://github.com/tromey/emacs-ffi

[2] https://github.com/skeeto/elisp-ffi

Re: State of Emacs Lisp on Guile

#64

Post by heintje_ghulam »

erik_seaberg wrote: post #58
heintje_ghulam wrote: post #53

Earlier quoted context omitted.

The problem with your point of view is that if it came to pass, then anyone who wanted to work on Emacs packages would have to learn multiple programming languages when before they only needed one, Elisp. Having packages in multiple languages hurts the ability of people to help contribute to each others' work (especially if they don't have time or space to learn multiple languages).

This smacks of the https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma . If we're afraid that people will want to write packages in Blub for some reason, and we refuse to accommodate Blub at all, we're just driving everyone to some other editor that embraces it.

I think the difference is that Emacs isn't a company, and it doesn't need to beat others in a competition, it just needs enough contributors to keep moving forward. Not everyone needs to use Emacs for Emacs to succeed in its goals.

Re: State of Emacs Lisp on Guile

#65

Post by nine_k »

ssivark wrote: post #54
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 :-\

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.

Re: State of Emacs Lisp on Guile

#66

Post by erik_seaberg »

heintje_ghulam wrote: post #64
erik_seaberg wrote: post #58

Earlier quoted context omitted.

This smacks of the https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma . If we're afraid that people will want to write packages in Blub for some reason, and we refuse to accommodate Blub at all, we're just driving everyone to some other editor that embraces it.

I think the difference is that Emacs isn't a company, and it doesn't need to beat others in a competition, it just needs enough contributors to keep moving forward. Not everyone needs to use Emacs for Emacs to succeed in its goals.

True, I was thinking of http://www.paulgraham.com/avg.html (where Lisp was Viaweb's "secret weapon"). And I'm worried about Emacs ending up with too small an audience of package maintainers to cover mainstream workplace use cases.
Post reply on HN