This article's "philosophy of Emacs" runs counter to the conventional wisdom that "Emacs is a good operating system, it just needs a decent text editor". If anything what the author describes is a "philosophy of Acme" -- do as much as possible by piping in and out of external processes. While Emacs can do this, there is no guiding principle to favor it over elisp extensions.<p>I think the philosophy of Emacs, if it has one, is "maximum extensibility". Whether that be with elisp or external processes matters not.<p>EDIT: forgot the word "conventional" :)
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.<p>[1] <a href="https://lists.gnu.org/archive/html/guile-user/2013-05/msg00081.html" rel="nofollow">https://lists.gnu.org/archive/html/guile-user/2013-05/msg000...</a><p>[2] <a href="https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/bpt/35002" rel="nofollow">https://www.google-melange.com/gsoc/proposal/review/google/g...</a>
This is actually really interesting from a vim user's perspective. We've long sought after an extension language as good as emacs lisp and finally now have gotten the news that vim plans to eventually phase out vimscript in favor of Python. The future looks good!
That's funny: for a dead project, there's an awful lot of traffic on emacs-devel, a big user community, lots of interesting new projects (like org-mode), and an amazing amount of utility.<p>If this is what a dead project looks like, the living really ought to envy the dead.
The article is extremely poorly translated, and many of the sentences don't make sense. This makes it hard for me to figure out if something was lost in translation or if the author is as ignorant as the translation makes him out to be.<p>I won't go through the post line by line; I think this paragraph sufficiently establishes that the author is ignorant.<p>> The virtue of Unix convention of making a big thing by combining small things is inherited in Emacs. This virtue itself is the reason why I am using Emacs. However, this may be becoming history. What is the meaning of the world without the virtue or philosophy, but with only benefit? I’d be disappointed if Emacs become so.<p>The precursors of Emacs were written at the AI lab at MIT, which at the time ran the ITS operating system. ITS had values that were pretty much orthogonal to Unix, which makes the statement especially ignorant. GNU Emacs's first public release in the 80s had to be ported to Unix to make it work.<p>Emacs is famous for being very extensible and can be used as a web browser, newsreader, spreadsheet, etc. You can do almost anything and never leave the Emacs environment. This is the opposite of combining many small programs to create something big.<p>Emacs also has a clear and logical design, and allows you redefine almost anything you don't like. Unix is famous for having a horrendous, incoherent design that is so poor that many of its commands are digestive noises (nroff, fsck, awk, grep). Its other commands are cryptically named and for years and years the documentation was nonexistent or terrible.
Although this article was written in 2010, his general complaint still applies. Compare a code-completion engine written for Emacs, with that written for Vim: auto-complete [1] is written completely in Elisp and utilizes Semantic as a source (mentioned in the article; also full Elisp), while a completion engine for Vim can be written in C++/ Python: Python is first-class, and it's a simple matter of invoking 'py import vim' [2] (it interfaces with the C++ code by simply importing the prebuilt ycm_core.so [3]). There is still no widely-used well-maintained clang completer for Emacs; the most dominant one spawns clang for everything [4].<p>That said, Emacs has a very rich Elisp ecosystem that's not going away anytime soon. By focusing on extensibility from the very beginning, Emacs has done many things right (it's just an Elisp interpreter with some editor functions bundled in); in comparison, Vim is a dumb-text editor focusing on keybindings, with extensibility as an afterthought. I don't think it is possible to replace Emacs today, primarily because writing a truly extensible text editor is a huge project with many boring parts, and there is no money to be made as a result. Elisp does have its drawbacks, and the Emacs community is suffering because of "philosophical" decisions like bzr (a dead project), instead of focusing on technical merit. So, the project will die a slow painful death, but I don't think that's happening anytime soon.<p>The takeaway is that Elisp needs to learn to interface with other languages better. There is a dead Elisp <-> Ruby bridge [5], but clearly not enough has been done about it.<p>[1]: <a href="https://github.com/auto-complete/auto-complete" rel="nofollow">https://github.com/auto-complete/auto-complete</a><p>[2]: <a href="https://github.com/Valloric/YouCompleteMe/blob/master/autoload/youcompleteme.vim#L41" rel="nofollow">https://github.com/Valloric/YouCompleteMe/blob/master/autolo...</a><p>[3]: <a href="https://github.com/Valloric/YouCompleteMe/blob/master/cpp/ycm/CMakeLists.txt#L20" rel="nofollow">https://github.com/Valloric/YouCompleteMe/blob/master/cpp/yc...</a><p>[4]: <a href="https://github.com/brianjcj/auto-complete-clang/blob/master/auto-complete-clang.el#L156" rel="nofollow">https://github.com/brianjcj/auto-complete-clang/blob/master/...</a><p>[5]: <a href="https://github.com/trogdoro/trogdoro-el4r" rel="nofollow">https://github.com/trogdoro/trogdoro-el4r</a>
TKF is an awesome (world class?) python and emacs/elisp developer. His projects have helped tune my emacs into a decently powerful python development vehicle. However, the level of effort required to get the basic functionality of a modern IDE like Pycharm has been daunting and required hours upon hours of fiddling.
re: the social value of emacs-lisp parsers/code-completion etc, perhaps someone could supply an API where other programs can query a headless emacs runtime. I defer to the author's experience when he says that emacs is a poor runtime for simultaneous editing + compute, but perhaps it's acceptable for compute-only (and this separate-process approach could in theory improve interactivity for the emacs editor as well).<p>My emacs at times can't keep up with my typing. But I love what it does for me. The lack of threading is a huge headache for elisp developers - they have to resort to manual cooperative-task-slicing hacks.
The biggest problem being Emacs isn't just a text editor. If it were, most if not all of these problems would have been resolved already. It's <i>very</i> hard to make repairs to a working bridge while in service and carrying rush-hour traffic. There's just so much predictability counted on by everyone who uses it, there are really no simple solutions.<p>I have to say though, external module(s) may be the way to go about it.<p>For the curious :<p><a href="http://www.emacswiki.org/emacs/TrampMode" rel="nofollow">http://www.emacswiki.org/emacs/TrampMode</a>
Speaking of Steve Yegge he is currently writing an 'ide as a service'. He recounts people has accused him of having the hidden agenda of advancing the cause of emacs. I think he would agree with m2ym's assessment of the philosophy of Emacs
"js2-mode is developed by an eccentric developer called Steve Yegge"<p>I think the translator didn't get it right when he/she called Steve Yegge "Eccentric." Google translate makes no mention of this, while Bing describes js2-mode as "unusual, which makes more sense:<p>"js2-mode new JavaScript for measure mode made by Developer Steve Yegge is somewhat unusual, as implemented in Emacs Lisp"
Regarding "no multi-threading support", I have often wished for a node.js-like abstraction for event-driven processing in elisp. Seems like it could take the pain out of writing modules that want to do interesting processing or network-heavy stuff (looking at you, CEDET over TRAMP).
Techendo has a good emacs tutorial for anyone looking: <a href="http://www.techendo.co/posts/techendo-tutorial-emacs-with-tim-jarratt" rel="nofollow">http://www.techendo.co/posts/techendo-tutorial-emacs-with-ti...</a>
Emacs, is obsolete but not for the reasons described in the article. I think the main problem is lack of smart IDE support. We can't easily define a language, a parser for it, reference resolve rules, analyze code, navigate reference, provide completion, etc. These features, not editors with a good text manipulation facilities get you the largest performance gain today.<p>Take a look where sublime, or IntelliJ is heading to. IntelliJ, for example, has a toolkit for quickly defining support for languages: <a href="https://github.com/JetBrains/Grammar-Kit" rel="nofollow">https://github.com/JetBrains/Grammar-Kit</a>
Emacs has been ported(I run it normally and haven't witnessed any issues) to GNU Guile. I assume that you could extend emacs with scheme, javascript, and soon lua.<p>Go have fun.
This is a very good point. Check out <a href="http://vimeo.com/39938276" rel="nofollow">http://vimeo.com/39938276</a>, a video about Ensime, a Scala/Java IDE as an external process. Daniel Spiewak makes largely the same point as this article: interprocess communication provides much better reusability than baking things in to a single process, whether that be Emacs or Eclipse.<p>bitwize makes another good point: this is less the "philosophy of Emacs", and more the philosophy of Unix (or perhaps, more specifically, Acme). It's ironic that some of the best parts of Emacs are the ones that look less like a Lisp Machine and more like a Unix pipeline, but there it is.