3 ms·

I don't agree with your view either. Going through C is not a counterargument, since it's doesn't compete with interactive development in Emacs Lisp. The techn

I don't agree with your view either. Going through C is not a counterargument, since it's doesn't compete with interactive development in Emacs Lisp. The technical drawbacks are many and for that very reason you see no fragmentation in the ecosystem today. Being able to write a Lua or JavaScript function on the fly, inside Emacs, and having Guile execute it would make these languages direct competitors to Emacs Lisp. You would expect to see newcomers take the easy way out and never bother with Emacs Lisp. Fragmentation. Dilution. That is the core issue. You seem to think that these sort of sacrifices should be made in the interest of popularity. I don't agree at all. Emacs has no reason to make populist compromises. It has certain qualities that have stood the test of time and have kept it extremely powerful. To go on the populist road would ensure that Emacs becomes just like everything else out there. A mediocrity.

pmoriarty 6y ago
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 compatibility. I'd also much prefer to write my own Emacs code in Scheme than eLisp (though, again, Guile Emacs does not entail replacing eLisp packages with Scheme -- you can still use eLisp if you want, and existing eLisp packages will still work).
- metroholografix 6y ago
  I don't think you'll be able to control occasional or not. This is a Pandora's box [1] situation. Either you open it or you don't. And having alternative languages as direct competitors to Emacs Lisp, available for interactive development, would certainly be blowing the box apart. I wouldn't mind Scheme as an alternative, the only alternative, except I don't think I'd use it myself since I would still see Emacs Lisp as domain-superior. Agreed on the rest, except as I said, none of that materialized from the Guile camp whilst we had plenty of that goodness emerge in core Emacs. [1] https://en.wikipedia.org/wiki/Pandora%27s_box https://en.wikipedia.org/wiki/Pandora%27s_box
- heintje_ghulam 6y ago
  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).
  - erik_seaberg 6y ago
    This smacks of the https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma 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.
    - heintje_ghulam 6y ago
      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.
      - erik_seaberg 6y ago
        True, I was thinking of http://www.paulgraham.com/avg.html 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.
  - nonbirithm 6y ago
    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.

pmoriarty 6y ago

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 compatibility. I'd also much prefer to write my own Emacs code in Scheme than eLisp (though, again, Guile Emacs does not entail replacing eLisp packages with Scheme -- you can still use eLisp if you want, and existing eLisp packages will still work).

metroholografix 6y ago
I don't think you'll be able to control occasional or not. This is a Pandora's box [1] situation. Either you open it or you don't. And having alternative languages as direct competitors to Emacs Lisp, available for interactive development, would certainly be blowing the box apart. I wouldn't mind Scheme as an alternative, the only alternative, except I don't think I'd use it myself since I would still see Emacs Lisp as domain-superior. Agreed on the rest, except as I said, none of that materialized from the Guile camp whilst we had plenty of that goodness emerge in core Emacs. [1] https://en.wikipedia.org/wiki/Pandora%27s_box https://en.wikipedia.org/wiki/Pandora%27s_box
heintje_ghulam 6y ago
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).
- erik_seaberg 6y ago
  This smacks of the https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma 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.
  - heintje_ghulam 6y ago
    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.
    - erik_seaberg 6y ago
      True, I was thinking of http://www.paulgraham.com/avg.html 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.
- nonbirithm 6y ago
  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.