5 ms·

I don't believe that Emacs is dead at all. Actually, most of the problems (multithreading, libraries, file I/O) raised by this article can be solved by replacin

by p4bl0 13y ago

I don't believe that Emacs is dead at all. Actually, most of the problems (multithreading, libraries, file I/O) raised by this article can be solved by replacing Emacs Lisp backend with Guile, which is an active and promising project [1,2]. As for Emacs philosophy, it might even survive Emacs (in the hypothetical situation where Emacs dies) if a project such as Emacsy (the second one presented in [1]) takes off. [1] https://lists.gnu.org/archive/html/guile-user/2013-05/msg00081.html https://lists.gnu.org/archive/html/guile-user/2013-05/msg000... [2] https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/bpt/35002 https://www.google-melange.com/gsoc/proposal/review/google/g...

tkf 13y ago
I think you misread the philosophy he talked about. He actually thinks that having the problems about threading, libraries and low APIs is a good thing, as it helps us maximizing social value of software we develop.
- hexd 13y ago
  He didn't say these problems are a "good thing" at all. He said externals in Emacs can be used elsewhere easily than Eclipse plugins, and that's the "good thing" (being decoupled, modular). Sometimes these problems are just a motivation, not a need, for using externals, and that's why he criticizes js2-mode and Semantic (as they're not externals). He's indeed talking about the Unix philosophy.
- espadrine 13y ago
  Guile integration may matter, assuming it happens (not everybody seems happy: https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00291.html https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00...) Python in Vim has slowly become the go-to choice to talk to an external program from Vim, because VimScript is simply that bad. I know little, however, about how hard ELisp makes it to interface with an external program. The examples he gives (a JS interpreter in ELisp, and Semantic) lead me to believe that the authors wrote all that in ELisp because it was easier than to play with an external program. Am I wrong? Will Guile ease the task of interfacing with an external program?
  - to3m 13y ago
    It's actually pretty easy to run external programs from elisp. stdin comes from a buffer, and stdout/stderr go to a buffer, and you can use all the usual emacs facilities on the result. See the various interactive modes (e.g., M-x run-python, M-x shell) for a demonstration. I suspect people who write packages entirely in elisp simply like elisp. And why not? The language itself is mostly OK to use, even if it doesn't always conform to modern standards.
    - tenfingers 13y ago
      To be honest, ELisp is not bad. Not in the same range as VimScript. In fact, ELisp with this weird concept of I/O through buffers makes a lot of sense for a text editor and I find it quite an elegant concept (not always practical, though). And while ELisp is not really CL, the lacking parts are the interpreter and runtime themselves, not the language. Writing elisp is not hard. What's hard is integrating all the modes, keymaps and quirky behavior of coupling all these smalls bits of code together. This is what makes emacs hard. Emacs, the "core editor" itself, is incredibly small. Way smaller than vim (build it by hand if you don't believe it). Emacs as the editor that you use every day is almost pure extensions. There's a /whole lot/ of global state in an editor. This is not going to change with Python, Guile or any other language. Users that complain about ELisp, most of the time actually never tried to write ELisp at all (they just glue some elisp around in .emacsrc). That's fine, but they don't realize what's going on under the hood. The C/C++ mode in emacs is completely different to the "stupid" syntax highlighting in Vim or most other editors. I normally recommend switching to another editor if after several years you still don't appreciate the difference. IMHO emacs, as it is, is a great editor. ELisp is part of the success (though guile would be a step forward).
jpollock 13y ago
When you get towards the bottom of the article, it actually says that this is a strength of emacs, and not a weakness. The claim is that the weak lisp interpreter encourages work to be done in other processes (reference to the awesome Tramp), thus making the feature available to other editors (Vim, TextMate), and the shell. The author compares this philosophy to Eclipse's where everything is a Java plugin written just for Eclipse. The claim that Emacs is dead rises from the shift in the latest versions to large included language processing plugins (JS2-Mode and Semantic) which provide rich language processing capabilities but are implemented in pure Emacs Lisp. The author closes off by stating, "The reason why Emacs platform is good is that it cooperates with OS, not because it is good by itself". In other words, the Unix philosophy. http://en.wikipedia.org/wiki/Unix_philosophy http://en.wikipedia.org/wiki/Unix_philosophy
- hollerith 13y ago
  The awesome Tramp, is it? IMHO, of all the software on my hard drive that I use regularly, Tramp is the most likely to break or hiccup in a novel or unfathomable way. It does fill a need or 3, I must admit, and I hate to be negative, but if that is the best example you can come up with of the positive effects of putting Emacs functionality in external programs, that makes me lean towards the conclusion that it is a bad idea to put Emacs functionality in external programs!
  - tkf 13y ago
    Some awesome Emacs Lisp programs that relies on external programs: mu4e: http://www.djcbsoftware.nl/code/mu/mu4e.html http://www.djcbsoftware.nl/code/mu/mu4e.html not much: http://notmuchmail.org/ http://notmuchmail.org/ EDBI: https://github.com/kiwanami/emacs-edbi https://github.com/kiwanami/emacs-edbi ropemacs: http://rope.sourceforge.net/ropemacs.html http://rope.sourceforge.net/ropemacs.html RSense: http://cx4a.org/software/rsense/index.html http://cx4a.org/software/rsense/index.html GCCSense: http://cx4a.org/software/gccsense/index.html http://cx4a.org/software/gccsense/index.html emacs-ipython-notebook: http://tkf.github.io/emacs-ipython-notebook http://tkf.github.io/emacs-ipython-notebook emacs-jedi: http://tkf.github.io/emacs-jedi http://tkf.github.io/emacs-jedi request.el: http://tkf.github.io/emacs-request/ http://tkf.github.io/emacs-request/ Well, the last three is my projects so you could exclude that :) Also, we could add version conrolling interfaces such as magit and VC (relying on git/svn/hg/...) and advanced interpreter such as SLIME/nrepl.el/geiser. Ah, and don't forget dired!
TylerE 13y ago
Why guile, which has exactly zero usage outside a few GNUtoys. Why not, e.g. Racket? If you're going to go the trouble, _get it right_.
- bitwize 13y ago
  Because Emacs is the ultimate GNUtoy.
- nahreally 13y ago
  Because it's been years in the works, it's finally about ready, and Racket only now is in everyone's mouths? Guile is now also able to run other languages as well, like Javascript, or at least so their maintainers claim. Besides, I know that among users of fringe languages like us (you too are, I presume) this is a bit of a taboo question... but who uses Racket so much as for it to make a difference here?
  - TylerE 13y ago
    Racket (Formally PLT Scheme) has been the dominant scheme for serious use for years. It's not "the n3w hawtness" by any means, but the established leader.
- espadrine 13y ago
  Emacs is an RMS-run GNU project. Back in 2002, the better choice was Common Lisp. One of CLISP's authors even made it work with Emacs over the course of a week-end [1]. There's never going to be the perfect fit for an embedded extension language. Hey, wasn't that what Lua wanted to be, and Tcl before it? Guile certainly isn't the easiest fit, but it's the only one that will get accepted. At least, if they slowly change the actual extension language away from ELisp, all extensions that rely on external programs will survive better. [1]: http://lists.gnu.org/archive/html/emacs-devel/2002-08/msg00040.html http://lists.gnu.org/archive/html/emacs-devel/2002-08/msg000...
- davexunit 13y ago
  Guile is a very capable Scheme implementation that was made to be the official GNU extension language. It features a very nice C API and FFI. Racket and Guile have different design goals. Guile fits Emacs' edit-the-editor-while-you-edit paradigm better.
melling 13y ago
Replacing Emacs Lisp with Guile has been active and promising for about a decade. http://stackoverflow.com/questions/1663627/guile-and-emacs http://stackoverflow.com/questions/1663627/guile-and-emacs I still use emacs a lot but these days I use IntelliJ for Java and Sublime Text for a lot of my other editing.
- monkmartinez 13y ago
  I'm not sure about you, but the level of effort required to keep my emacs.d up to date and the level of effort required for each project has turned me away from emacs as my main development environment.
  - philsnow 13y ago
    How much effort do you have to put in to keep your .emacs.d up to date ? I only started using emacs in emacs 22, so I haven't had to keep things working for 5-10 major releases like I'm sure some people have, but my init.el and .emacs.d have been pretty static the whole time.
    - monkmartinez 13y ago
      Do you follow @melpa_emacs on twitter? Packages are not static by a loooooong shot. I am mainly interested in using emacs for Python, Org-mode, JS, HTML. In terms of years of use, I am on year three or so... but I like to keep my shit on lock. My biggest mistake was trying Pycharm. Now I constantly compare Emacs to Pycharm... and it just doesn't compare.
      - philsnow 13y ago
        I build my emacs from trunk every ~1-3 months for No Good Reason (tm), and I scarcely ever have anything in my own configuration (init.el, custom.el, various random things I've installed in ~/.emacs.d) break. (I also edit python in emacs regularly, not sure what's changed in the last N years)
      - 13y ago

by p4bl0 13y ago

tkf 13y ago

I think you misread the philosophy he talked about. He actually thinks that having the problems about threading, libraries and low APIs is a good thing, as it helps us maximizing social value of software we develop.

hexd 13y ago
He didn't say these problems are a "good thing" at all. He said externals in Emacs can be used elsewhere easily than Eclipse plugins, and that's the "good thing" (being decoupled, modular). Sometimes these problems are just a motivation, not a need, for using externals, and that's why he criticizes js2-mode and Semantic (as they're not externals). He's indeed talking about the Unix philosophy.
espadrine 13y ago
Guile integration may matter, assuming it happens (not everybody seems happy: https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00291.html https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00...) Python in Vim has slowly become the go-to choice to talk to an external program from Vim, because VimScript is simply that bad. I know little, however, about how hard ELisp makes it to interface with an external program. The examples he gives (a JS interpreter in ELisp, and Semantic) lead me to believe that the authors wrote all that in ELisp because it was easier than to play with an external program. Am I wrong? Will Guile ease the task of interfacing with an external program?
- to3m 13y ago
  It's actually pretty easy to run external programs from elisp. stdin comes from a buffer, and stdout/stderr go to a buffer, and you can use all the usual emacs facilities on the result. See the various interactive modes (e.g., M-x run-python, M-x shell) for a demonstration. I suspect people who write packages entirely in elisp simply like elisp. And why not? The language itself is mostly OK to use, even if it doesn't always conform to modern standards.
  - tenfingers 13y ago
    To be honest, ELisp is not bad. Not in the same range as VimScript. In fact, ELisp with this weird concept of I/O through buffers makes a lot of sense for a text editor and I find it quite an elegant concept (not always practical, though). And while ELisp is not really CL, the lacking parts are the interpreter and runtime themselves, not the language. Writing elisp is not hard. What's hard is integrating all the modes, keymaps and quirky behavior of coupling all these smalls bits of code together. This is what makes emacs hard. Emacs, the "core editor" itself, is incredibly small. Way smaller than vim (build it by hand if you don't believe it). Emacs as the editor that you use every day is almost pure extensions. There's a /whole lot/ of global state in an editor. This is not going to change with Python, Guile or any other language. Users that complain about ELisp, most of the time actually never tried to write ELisp at all (they just glue some elisp around in .emacsrc). That's fine, but they don't realize what's going on under the hood. The C/C++ mode in emacs is completely different to the "stupid" syntax highlighting in Vim or most other editors. I normally recommend switching to another editor if after several years you still don't appreciate the difference. IMHO emacs, as it is, is a great editor. ELisp is part of the success (though guile would be a step forward).

jpollock 13y ago

When you get towards the bottom of the article, it actually says that this is a strength of emacs, and not a weakness. The claim is that the weak lisp interpreter encourages work to be done in other processes (reference to the awesome Tramp), thus making the feature available to other editors (Vim, TextMate), and the shell. The author compares this philosophy to Eclipse's where everything is a Java plugin written just for Eclipse. The claim that Emacs is dead rises from the shift in the latest versions to large included language processing plugins (JS2-Mode and Semantic) which provide rich language processing capabilities but are implemented in pure Emacs Lisp. The author closes off by stating, "The reason why Emacs platform is good is that it cooperates with OS, not because it is good by itself". In other words, the Unix philosophy. http://en.wikipedia.org/wiki/Unix_philosophy http://en.wikipedia.org/wiki/Unix_philosophy

hollerith 13y ago
The awesome Tramp, is it? IMHO, of all the software on my hard drive that I use regularly, Tramp is the most likely to break or hiccup in a novel or unfathomable way. It does fill a need or 3, I must admit, and I hate to be negative, but if that is the best example you can come up with of the positive effects of putting Emacs functionality in external programs, that makes me lean towards the conclusion that it is a bad idea to put Emacs functionality in external programs!
- tkf 13y ago
  Some awesome Emacs Lisp programs that relies on external programs: mu4e: http://www.djcbsoftware.nl/code/mu/mu4e.html http://www.djcbsoftware.nl/code/mu/mu4e.html not much: http://notmuchmail.org/ http://notmuchmail.org/ EDBI: https://github.com/kiwanami/emacs-edbi https://github.com/kiwanami/emacs-edbi ropemacs: http://rope.sourceforge.net/ropemacs.html http://rope.sourceforge.net/ropemacs.html RSense: http://cx4a.org/software/rsense/index.html http://cx4a.org/software/rsense/index.html GCCSense: http://cx4a.org/software/gccsense/index.html http://cx4a.org/software/gccsense/index.html emacs-ipython-notebook: http://tkf.github.io/emacs-ipython-notebook http://tkf.github.io/emacs-ipython-notebook emacs-jedi: http://tkf.github.io/emacs-jedi http://tkf.github.io/emacs-jedi request.el: http://tkf.github.io/emacs-request/ http://tkf.github.io/emacs-request/ Well, the last three is my projects so you could exclude that :) Also, we could add version conrolling interfaces such as magit and VC (relying on git/svn/hg/...) and advanced interpreter such as SLIME/nrepl.el/geiser. Ah, and don't forget dired!

TylerE 13y ago

Why guile, which has exactly zero usage outside a few GNUtoys. Why not, e.g. Racket? If you're going to go the trouble, _get it right_.

bitwize 13y ago
Because Emacs is the ultimate GNUtoy.
nahreally 13y ago
Because it's been years in the works, it's finally about ready, and Racket only now is in everyone's mouths? Guile is now also able to run other languages as well, like Javascript, or at least so their maintainers claim. Besides, I know that among users of fringe languages like us (you too are, I presume) this is a bit of a taboo question... but who uses Racket so much as for it to make a difference here?
- TylerE 13y ago
  Racket (Formally PLT Scheme) has been the dominant scheme for serious use for years. It's not "the n3w hawtness" by any means, but the established leader.
espadrine 13y ago
Emacs is an RMS-run GNU project. Back in 2002, the better choice was Common Lisp. One of CLISP's authors even made it work with Emacs over the course of a week-end [1]. There's never going to be the perfect fit for an embedded extension language. Hey, wasn't that what Lua wanted to be, and Tcl before it? Guile certainly isn't the easiest fit, but it's the only one that will get accepted. At least, if they slowly change the actual extension language away from ELisp, all extensions that rely on external programs will survive better. [1]: http://lists.gnu.org/archive/html/emacs-devel/2002-08/msg00040.html http://lists.gnu.org/archive/html/emacs-devel/2002-08/msg000...
davexunit 13y ago
Guile is a very capable Scheme implementation that was made to be the official GNU extension language. It features a very nice C API and FFI. Racket and Guile have different design goals. Guile fits Emacs' edit-the-editor-while-you-edit paradigm better.

melling 13y ago

Replacing Emacs Lisp with Guile has been active and promising for about a decade. http://stackoverflow.com/questions/1663627/guile-and-emacs http://stackoverflow.com/questions/1663627/guile-and-emacs I still use emacs a lot but these days I use IntelliJ for Java and Sublime Text for a lot of my other editing.

monkmartinez 13y ago
I'm not sure about you, but the level of effort required to keep my emacs.d up to date and the level of effort required for each project has turned me away from emacs as my main development environment.
- philsnow 13y ago
  How much effort do you have to put in to keep your .emacs.d up to date ? I only started using emacs in emacs 22, so I haven't had to keep things working for 5-10 major releases like I'm sure some people have, but my init.el and .emacs.d have been pretty static the whole time.
  - monkmartinez 13y ago
    Do you follow @melpa_emacs on twitter? Packages are not static by a loooooong shot. I am mainly interested in using emacs for Python, Org-mode, JS, HTML. In terms of years of use, I am on year three or so... but I like to keep my shit on lock. My biggest mistake was trying Pycharm. Now I constantly compare Emacs to Pycharm... and it just doesn't compare.
    - philsnow 13y ago
      I build my emacs from trunk every ~1-3 months for No Good Reason (tm), and I scarcely ever have anything in my own configuration (init.el, custom.el, various random things I've installed in ~/.emacs.d) break. (I also edit python in emacs regularly, not sure what's changed in the last N years)
    - 13y ago