
Clarifying some things about Guile-Emacs - paroneayea
https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00559.html
======
jwr
This is a good clarification. I was worried about Scheme becoming the
"official" Emacs extension language, which I think is a bad idea. Getting a
better/faster Elisp engine is a good goal.

I can't help but think that Emacs is a local maximum: it works well enough
that people don't take on the task of implementing huge changes. People who
demand a lot from Emacs learn how to do things in Elisp and just get on.

As for the future, I would love to see an Emacs implemented in Clojure (no,
not ClojureScript, Clojure on the JVM). I think approaching this task with any
Lisp-like language other than Clojure is misguided, because it doesn't take
concurrency into account. Clojure is the only Lisp-family language which gets
concurrency right. Also, I'd love to have easy access to Java libraries. But,
that's just me dreaming.

~~~
josteink
Being based on Clojure for good and bad also means being dependant on the JVM.
Not taking RMS's stance on Free software with a capitol F into account (and
make no mistake that Emacs _is_ RMS's baby, it wont happen), the JVM is a
troublesome dependency in itself.

OpenJDK has terrible performance. Oracle JVM has terrible licensing and
platform support.

For the "emerging" platforms such as ARM that means that anything based on JVM
is inaccessible, unless you are willing to accept a 30 second+ startup-time
for any JVM based application.

If you have any doubts about this, try getting Clojure and the appropriate
tooling working on a Raspberry Pi. You will be tearing your hair out before
having written a single line of code. While the rest of the Linux userland
(based on C) just flows by at a nice regular speed.

The JVM situation (either open, supported and slow, or not supported at all)
makes Clojure a no-go on this entire platform.

While I'm not saying we should limit Emacs to what runs well on a RPi, I think
it's worth considering ARM as a critical platform to support in the future,
and the JVM has no room there. At all.

~~~
rjsw
OpenJDK performance seems fine to me, on platforms that have HotSpot support.

I'm not arguing that Emacs should target the JVM but don't see how building it
on yet another bytecode VM is going to fix any performance problems.

~~~
lake99
When I write command-line programs, the JVM seems just fine. Even the startup
time is not bad. However, when I compare actual editors and IDEs, JVM-based
editors feel as painful as pulling teeth. Compare jEdit and Kate, or even
Sublime Text. Or compare Eclipse, IntelliJ, Netbeans, etc. with any native
app. Sure, these IDEs do a lot, but when I'm editing some UML diagram in
Eclipse, for example, just clicking on an element to see its properties takes
a few seconds. Seems like Eclipse is using _all_ its libraries to accomplish
this. I'm not running these on netbooks. I am comparing speeds across fairly
well-endowed laptops and desktops. Maybe the fault lies not with JVM, but with
the rest of the Java ecosystem.

------
JasonFruit
Also notice on a different branch of the thread, where rms says, "Guile is the
direction we should go, if at all possible." It sounds to me like Guile, at
least as Emacs' elisp implementation, is one way Emacs _could_ go, a way it
_should_ go, and the way rms _says_ it should go; all that suggests strongly
that it is the way it _will_ go.

~~~
naner
[https://lists.gnu.org/archive/html/emacs-
devel/2014-09/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2014-09/msg00527.html)

Heh, nice email header.

Guile is an old GNU project
([https://www.gnu.org/software/guile/manual/html_node/History....](https://www.gnu.org/software/guile/manual/html_node/History.html)),
it languished for a long time but recent developments have really pushed it
forward.

~~~
chriswarbo
> Guile is an old GNU project, it languished for a long time but recent
> developments have really pushed it forward.

A bit like Emacs then ;)

(it seems much more active around v24 onwards)

~~~
fafner
Once rms stepped down as a maintainer development around GNU Emacs seemed to
have significantly improved. It is amazing to see the progress. Although the
24.4 release keeps waiting.

------
josteink
Awesome! I like how he clarifies what this is, isn't and what state it is in.
I was definitely wondering where this project was and where it was heading.

I also appreciate how he claims it build cleanly too. Almost feel like
building it and trying it myself :-)

------
mapcar
I think the most important thing would be for the community to understand what
ports and what doesn't port from the elisp version that everyone uses- until
then I don't think many will be able to make an informed decision regarding
the risks of migrating.

~~~
rcthompson
It looks like it's supposed to be backwards-compatible with pretty much all
existing elisp code.

~~~
mapcar
Right, it's the "pretty much" part that's a little disturbing. Would be nice
to know why this caveat is always thrown around.

~~~
davexunit
One example is that some extensions such as Gnus have contain code written in
the current Elisp interpreter's bytecode, which is incompatible with the Guile
VM.

~~~
parfe
From the submitted email:

>Guile-Emacs loads, compiles and executes the programs included in Emacs by
default, plus Gnus, Org-Mode, and more.

