"Lack of some features, most notably FFI and concurrency." Cool -- my '90s hacks are in demand! I added threading support to Guile and wrote libffi back in the 90s.
Thanks for writing libffi! It's given us so many cool possibilities.
Emacs Lisp's Future
71–80 of 160 posts
Re: Emacs Lisp's Future
#72Why isn't Lua even a choice? It's small, portable, easily embeddable, lightning fast, supports high-level functional programming idioms, and is extremely flexible in creating and enforcing policies (via metaprogramming).
Re: Emacs Lisp's Future
#73If it isn't broken, don't try to fix it.
I am an old guy (professional Lisp developer since about 1981) and my age probably affects my opinion:
It would be a disaster to mess up the Emacs ecosystem. I don't think that Emacs/elisp runs slowly and since I have to use so many different programming languages anyway, needing to know a little elisp is no problem.
I don't care if elisp is not a modern language.
Way off topic, something that I have written before about: think forwards several hundred years. What will the software landscape look like? My bet is that there will be many ancient software systems that have been debugged to near absolute stability over the centuries. Sure new software will be written, but I bet there will be many very old and stable systems that will see little change.
Re: Emacs Lisp's Future
#74Earlier quoted context omitted.
Too often it seems RMS is why GNU can't have nice things.
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)
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.
Re: Emacs Lisp's Future
#75Earlier quoted context omitted.
Literally dozens more. Look, neither Common Lisp nor any Scheme implementation are exactly topping the charts in popularity these days. This should be about the technical merits of the choice, because I'm pretty sure Emacs Lisp both has more code and more programmers (both represented in the forms of small scripts we've shoved into scratch and evaluated) than both.
The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s. GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile…
People seem to think that moving to Guile means moving to Scheme. It does not. It means that Elisp will run on Guile's VM, which will bring many practical advantages. Emacs will not be switching to Scheme. Elisp will still be used and the Elisp language can continue to be developed.
Re: Emacs Lisp's Future
#76Earlier quoted context omitted.
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.
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…
Are you sure that Richard Stallman does not like Common Lisp?
Several years ago he asked me about the possibility of my releasing my out of print Common Lisp book (published by Springer-Verlag) under the GNU documentation license. I would have liked to do that but I couldn't find my manuscript word processing files.
Re: Emacs Lisp's Future
#77Earlier quoted context omitted.
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.
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…
>Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway
Guile is already a general VM meant to support many different languages, not only Scheme. I think it's a very clean solution to use Guile's efficient VM, and I don't think minimalistic is a useful criterion.
Re: Emacs Lisp's Future
#78Dream: "Common Lisp/Guile, and a Chromium based rendering engine".
Maybe I'm in the minority, but I for one really appreciate how Emacs can run in a terminal, over SSH, with almost no feature-degradation at all. Besides Emacs being a very nice programming (and programmable editor), this is one the key features which keeps me from even considering other more "modern" options.
Exactly right! I spend tons of time running Emacs over ssh. This is a major value add of Emacs. The -nw option is our friend :-)
Re: Emacs Lisp's Future
#79Given 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/…
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.
Re: Emacs Lisp's Future
#80Why isn't Lua even a choice? It's small, portable, easily embeddable, lightning fast, supports high-level functional programming idioms, and is extremely flexible in creating and enforcing policies (via metaprogramming).
Because it is a completely different language and would require rewriting all of the thousands of packages by hand (and centuries of human labor)?