3 ms·

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

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 12y ago
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.
- technomancy 12y ago
  The main performance problems are load time and ARM performance. But moving a flagship GNU project to a runtime with serious patent encumbrance is clearly never going to happen.
- lake99 12y ago
  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.
quadcore4 12y ago
> > As for the future, I would love to see an Emacs implemented in Clojure > Being based on Clojure for good and bad also means being dependant on the JVM. {snip} The JVM situation (either open, supported and slow, or not supported at all) makes Clojure a no-go on this entire platform. Maybe the solution is that we need a Clojure implemented on Guile. Edit: That would make a number of groups of people happy: * the free-software advocates who like Clojure don't like its current license (EPL) * the folks who like Clojure but don't want to use the JVM or anything else Java-related * the people who want to use Clojure on JVM but cannot tolerate its slow start-up time and/or high memory usage * the group who would like to re-implement Emacs, but not in Elisp, Scheme, or CL * (Edit 2) the Guile dev team, who would get an influx of new users * (Edit 3) GNU folks, who would see more people exposed to GNU and Guile Aside, not sure what the multi-threading story of a Guile-Clojure would look like.
- tree_of_item 12y ago
  Clojure in Guile is interesting, but seems orthogonal to the Emacs question. I mean, we're not going to implement Clojure in Guile just to implement Emacs in Clojure, are we? That doesn't even avoid the issue being brought up here, which is interaction between Emacs Lisp and Scheme.

rjsw 12y ago

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.

technomancy 12y ago
The main performance problems are load time and ARM performance. But moving a flagship GNU project to a runtime with serious patent encumbrance is clearly never going to happen.
lake99 12y ago
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.

quadcore4 12y ago

> > As for the future, I would love to see an Emacs implemented in Clojure > Being based on Clojure for good and bad also means being dependant on the JVM. {snip} The JVM situation (either open, supported and slow, or not supported at all) makes Clojure a no-go on this entire platform. Maybe the solution is that we need a Clojure implemented on Guile. Edit: That would make a number of groups of people happy: * the free-software advocates who like Clojure don't like its current license (EPL) * the folks who like Clojure but don't want to use the JVM or anything else Java-related * the people who want to use Clojure on JVM but cannot tolerate its slow start-up time and/or high memory usage * the group who would like to re-implement Emacs, but not in Elisp, Scheme, or CL * (Edit 2) the Guile dev team, who would get an influx of new users * (Edit 3) GNU folks, who would see more people exposed to GNU and Guile Aside, not sure what the multi-threading story of a Guile-Clojure would look like.

tree_of_item 12y ago
Clojure in Guile is interesting, but seems orthogonal to the Emacs question. I mean, we're not going to implement Clojure in Guile just to implement Emacs in Clojure, are we? That doesn't even avoid the issue being brought up here, which is interaction between Emacs Lisp and Scheme.