7 ms·

Given all the reworks of software projects that have a) been started b) then delayed c) then delayed more, "because this time we'll make it perfect" and d) then

by yason 12y ago

Given all the reworks of software projects that have a) been started b) then delayed c) then delayed more, "because this time we'll make it perfect" and d) then failed to gather traction because of incompatibilities, it's my humble guess that the only way would be to continue ELisp as it is and slowly rework the compiler/interpreter and the runtime into a more modern codebase, and add missing features such as thread/process based concurrency. Guile, Clojure, Common Lisp or whatever language are going to basically restart Emacs from scratch, no matter how well they're coated with compatibility macros. It's better to create slight incompatibilities gradually (so that packages can catch up in some humane timeframe). I could imagine the ELisp runtime being intertwined with the Emacs C code badly enough that making radical changes to it would seem "impossible", just like in the CPython codebase it is considered impossible to ditch GIL and modernise the code. But those kind of comments are often excuses because people are lazy and it's nicer to write new code.

easytiger 12y ago
Agreed. This is busy work. If emacs were a pay for commercial product then this wouldn't be considered because emacs is still proving itself economically viable. Considering how intricately it is integrated into a lot of people's lives this is silly. It's fine sitting on a an academic pedestal but some of us have to live in the real world. Also I'm not sure how the maintainer failed to address your suggestion as it seems the most logical... which makes me worry this is an academic exercise. Besides the point... almost nothing will be achieved by making elsip faster. I sometimes write macros to work on GBs of files and yes, it isn't fast... but if i cared about speed i'd be shelling out to cli tools to do the work anyway. Makes. No. Sense. Fork it if you must and leave the rest of us alone.
p4bl0 12y ago
As a programming language aficionado, I get really excited by the idea of Guile-Emacs. Yet I couldn't agree more with what you just said. Breaking Emacs Lisp would be a disaster, evolving it slowly to add support for the desired features seems a much more reasonable choice. Not only on the side of package maintainers but also on emacs developer's: at least any effort is worthwhile, since it will be a little step of improvement on actual Emacs rather than starting or continuing a project which has more chance to be abandoned at some point than to merge into the main Emacs branch.
JulianMorrison 12y ago
If I was them, I'd gradually introduce the minimum set of breaking changes to ELisp that converge it on Common Lisp. Even if those changes were unhelpful or removed features. Then eventually, when it maps 1:1 onto a subset of CL, just swap the implementation for a supported CL.
- mjn 12y ago
  Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway. The semantics of Elisp/Scheme are too different to be able to just stick in a Scheme implementation with a smallish compatibility layer, like you could with Elisp hosted on CL.
  - JulianMorrison 12y ago
    Too often it seems RMS is why GNU can't have nice things.
    - fleitz 12y ago
      RMS would never let practicality get in the way of ideology. The GNU/RMS is best because you're free! (As long as your computing needs are a text editor, compiler, and some unix system utils)
      - rurban 12y ago
        That's why I believe their FFI plans are doomed. We implemented FFI's for emacs over the last decades, but RMS always strongly opposed it, because you could call windows DLL's then. gtk-emacs e.g.
DennisP 12y ago
Right. Javascript used to be slow, but instead of bemoaning how slow it was and thinking maybe they should change languages, people made Javascript fast. If it can be done with Javascript, why not Elisp?
- adrianN 12y ago
  Because Javascript has huge players like Google, Microsoft and Mozilla behind it that throw insane ressources at it to compete for performance, whereas EMacs is fast enough for most of its users and has no big companies interested in its performance.
  - DennisP 12y ago
    Hmm. I wonder whether a Javascript vm could be used for Elisp. Of course Javascript is lexically scoped but there's a way to hack around that: http://stackoverflow.com/questions/10060857/is-it-possible-to-achieve-dynamic-scoping-in-javascript-without-resorting-to-eva http://stackoverflow.com/questions/10060857/is-it-possible-t... Of course there'd be no point if emacs were fast enough, but there seems to be a significant number of people who feel it's not.
tedks 12y ago
Guile can run elisp already, IIRC. There's no compatibility issue, it would just be a runtime change. And then you'd get Guile's VM, which is very nice and also polyglot(tic?). Guile is a language-agnostic VM, not a language itself, and a frontend already exists for elisp.
- wtbob 12y ago
  > There's no compatibility issue That's not really true, is it though? Scheme '(), #f and so forth...
  - tedks 12y ago
    As I said in my comment, >Guile can run elisp already Guile already interprets Elisp. Elisp can run unmodified on Guile. Guile, the virtual machine, contains a front-end for Emacs Lisp. المكر ينفذ أصلا إيماكس اللثغة. Guile jatorriz exekutatzen emacs Lisp. It is true there are no compatibility issues because Guile is an implementation of Emacs Lisp.
    - wtbob 12y ago
      From the same thread https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00500.html https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00... > It's not a 100% drop-in replacement, that's true…(eq foo t) should always work. (eq foo nil) will only work if that `nil' came from Elisp code; if it's a Scheme #f or '() in disguise, then you need to make that (not foo) or (null foo) (both works in both cases); anything but (eq foo nil).
      - tedks 12y ago
        That seems to imply that the problem is in the Scheme/Elisp interface, not in Guile's execution of pure Elisp.
      - taylanub 12y ago
        Note that using the `not' and `null' functions instead of comparing equality to `nil' is good coding style anyway.
adamc 12y ago
I agree with all of this as an emacs user, but I wonder whether this sets up emacs to be replaced by something that uses a more popular extension language, like Atom. Won't happen in the next 5 years, but 10 years down the line, being based on JavaScript might look like a great decision. I love lisp but I don't see much interest in it and have had coworkers tell me it keeps them away from emacs. Which is a bit sad...
- bachmeier 12y ago
  I think emacs lisp is a great extension language. There's not much syntax, and it has the important functionality baked in. IMO anyone that says they don't use Emacs because they don't like Lisp is someone that would not use Emacs no matter what.
taylanub 12y ago
Guile-Emacs is not a rework, it's a rebase. It already runs all Elisp, sans bugs and (currently severe) performance regressions. It will be a nearly-drop-in replacement, a new version of GNU Emacs, even less different from it than XEmacs. In general, it will only add to Emacs, and change the underlying implementation of Elisp.

by yason 12y ago

easytiger 12y ago

Agreed. This is busy work. If emacs were a pay for commercial product then this wouldn't be considered because emacs is still proving itself economically viable. Considering how intricately it is integrated into a lot of people's lives this is silly. It's fine sitting on a an academic pedestal but some of us have to live in the real world. Also I'm not sure how the maintainer failed to address your suggestion as it seems the most logical... which makes me worry this is an academic exercise. Besides the point... almost nothing will be achieved by making elsip faster. I sometimes write macros to work on GBs of files and yes, it isn't fast... but if i cared about speed i'd be shelling out to cli tools to do the work anyway. Makes. No. Sense. Fork it if you must and leave the rest of us alone.

p4bl0 12y ago

As a programming language aficionado, I get really excited by the idea of Guile-Emacs. Yet I couldn't agree more with what you just said. Breaking Emacs Lisp would be a disaster, evolving it slowly to add support for the desired features seems a much more reasonable choice. Not only on the side of package maintainers but also on emacs developer's: at least any effort is worthwhile, since it will be a little step of improvement on actual Emacs rather than starting or continuing a project which has more chance to be abandoned at some point than to merge into the main Emacs branch.

JulianMorrison 12y ago

If I was them, I'd gradually introduce the minimum set of breaking changes to ELisp that converge it on Common Lisp. Even if those changes were unhelpful or removed features. Then eventually, when it maps 1:1 onto a subset of CL, just swap the implementation for a supported CL.

mjn 12y ago
Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway. The semantics of Elisp/Scheme are too different to be able to just stick in a Scheme implementation with a smallish compatibility layer, like you could with Elisp hosted on CL.
- JulianMorrison 12y ago
  Too often it seems RMS is why GNU can't have nice things.
  - fleitz 12y ago
    RMS would never let practicality get in the way of ideology. The GNU/RMS is best because you're free! (As long as your computing needs are a text editor, compiler, and some unix system utils)
    - rurban 12y ago
      That's why I believe their FFI plans are doomed. We implemented FFI's for emacs over the last decades, but RMS always strongly opposed it, because you could call windows DLL's then. gtk-emacs e.g.

DennisP 12y ago

Right. Javascript used to be slow, but instead of bemoaning how slow it was and thinking maybe they should change languages, people made Javascript fast. If it can be done with Javascript, why not Elisp?

adrianN 12y ago
Because Javascript has huge players like Google, Microsoft and Mozilla behind it that throw insane ressources at it to compete for performance, whereas EMacs is fast enough for most of its users and has no big companies interested in its performance.
- DennisP 12y ago
  Hmm. I wonder whether a Javascript vm could be used for Elisp. Of course Javascript is lexically scoped but there's a way to hack around that: http://stackoverflow.com/questions/10060857/is-it-possible-to-achieve-dynamic-scoping-in-javascript-without-resorting-to-eva http://stackoverflow.com/questions/10060857/is-it-possible-t... Of course there'd be no point if emacs were fast enough, but there seems to be a significant number of people who feel it's not.

tedks 12y ago

Guile can run elisp already, IIRC. There's no compatibility issue, it would just be a runtime change. And then you'd get Guile's VM, which is very nice and also polyglot(tic?). Guile is a language-agnostic VM, not a language itself, and a frontend already exists for elisp.

wtbob 12y ago
> There's no compatibility issue That's not really true, is it though? Scheme '(), #f and so forth...
- tedks 12y ago
  As I said in my comment, >Guile can run elisp already Guile already interprets Elisp. Elisp can run unmodified on Guile. Guile, the virtual machine, contains a front-end for Emacs Lisp. المكر ينفذ أصلا إيماكس اللثغة. Guile jatorriz exekutatzen emacs Lisp. It is true there are no compatibility issues because Guile is an implementation of Emacs Lisp.
  - wtbob 12y ago
    From the same thread https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00500.html https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00... > It's not a 100% drop-in replacement, that's true…(eq foo t) should always work. (eq foo nil) will only work if that `nil' came from Elisp code; if it's a Scheme #f or '() in disguise, then you need to make that (not foo) or (null foo) (both works in both cases); anything but (eq foo nil).
    - tedks 12y ago
      That seems to imply that the problem is in the Scheme/Elisp interface, not in Guile's execution of pure Elisp.
    - taylanub 12y ago
      Note that using the `not' and `null' functions instead of comparing equality to `nil' is good coding style anyway.

adamc 12y ago

I agree with all of this as an emacs user, but I wonder whether this sets up emacs to be replaced by something that uses a more popular extension language, like Atom. Won't happen in the next 5 years, but 10 years down the line, being based on JavaScript might look like a great decision. I love lisp but I don't see much interest in it and have had coworkers tell me it keeps them away from emacs. Which is a bit sad...

bachmeier 12y ago
I think emacs lisp is a great extension language. There's not much syntax, and it has the important functionality baked in. IMO anyone that says they don't use Emacs because they don't like Lisp is someone that would not use Emacs no matter what.

taylanub 12y ago

Guile-Emacs is not a rework, it's a rebase. It already runs all Elisp, sans bugs and (currently severe) performance regressions. It will be a nearly-drop-in replacement, a new version of GNU Emacs, even less different from it than XEmacs. In general, it will only add to Emacs, and change the underlying implementation of Elisp.