[jrockway]

I guess I should really participate in emacs-devel a bit more, but I've always been in favor of allowing Emacs to support multiple languages with a common runtime. Emacs Lisp is slow, that's true, but there's no problem intrinsic to its syntax that makes it slow. Similarly, there's nothing intrinsically slow about the runtime that Emacs provides; it's a bog standard dynamically-typed language with the slow stuff implemented in C. What we need is a proper compiler, one that can compile Emacs Lisp to either native code, or a proper intermediate representation that can be optimized. Unladen Swallow seems like a good model.

With a proper intermediate representation, we can begin writing compilers for other languages. Then you can write your extensions in Common Lisp, or Emacs Lisp, or Scheme, or JavaScript, or Perl, or whatever you feel like writing a compiler for. This won't fragment the community, because the runtime will be the same for every language; yes, there will be syntax differences, but in the end, everyone is programming to the same API. This is different than what Vim does with its programming language support (recompile Vim to embed opaque interpreter object, pray when you choose more than one language).

The only problem is that Emacs Lisp is fine for 99.9% of use cases, and it's fast enough for 99.9% of use cases. One worry I have about "proper language support" is that people will start "engineering" Emacs extensions. (By which I mean, treating software designed for interactive use by programmers as though it's "enterprise" software. When you need to write software that must not fail, concepts like encapsulation are very important. But when you're writing software that's designed to be edited by the user while it's running, you can't write it that way. Emacs Lisp explicitly encourages this, but CL, Scheme, and JavaScript don't.)

[technomancy]

> What we need is a proper compiler, one that can compile Emacs Lisp to either native code

This has actually been done (possibly badly?) and turned out to be a wash in terms of performance.

[jrockway]

Yeah. It might be worth trying again, considering the good performance of newer language runtimes like SBCL, Node.js, and Unladen Swallow.

[dextorious]

What "unladen swallow"? That project did not have the expected improvements and was abandoned...

[jrockway]

Unladen Swallow might not be usable in production, but as a research project it's pretty interesting. One of its problems was supporting C-based extensions, but that's not a requirement for Emacs Lisp, and so a similar project might be more effective for Emacs than for Python. (I also like the idea of using LLVM for dynamic language runtimes, but as time goes forward this seems less likely to work out.)

[lelele]

I think one of the strength of Emacs, that has allowed it to grow that much compared to Vim, is that it has always had one official extension language. It doesn't have any external dependencies. If Emacs developers endorsed extending Emacs with other languages, users would have started using other languages libraries, which could have caused issues in portability and set up.