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".

http://en.wikipedia.org/wiki/Unix_philosophy

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!

mu4e: http://www.djcbsoftware.nl/code/mu/mu4e.html

not much: http://notmuchmail.org/

EDBI: https://github.com/kiwanami/emacs-edbi

ropemacs: http://rope.sourceforge.net/ropemacs.html

RSense: http://cx4a.org/software/rsense/index.html

GCCSense: http://cx4a.org/software/gccsense/index.html

emacs-ipython-notebook: http://tkf.github.io/emacs-ipython-notebook

emacs-jedi: http://tkf.github.io/emacs-jedi

request.el: 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!

well, emacs claims to be cross-platform, what happens when you are on a non-unix like system ?

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?

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.

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).

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.

What are you doing with emacs.d that requires a burdensome level of effort to keep it "up to date"? What does that even mean? I've been using Emacs almost 10 years, and I very infrequently modify my emacs.d, and I don't know many people who do. Sure, I could spend a lot of time tweaking it and messing around with it, but it'd be an entirely self inflicted thing, and not the fault of Emacs. I could spend all day fiddling with .vimrc, or the Visual Studio settings, too.

I also don't understand the what you mean by "the level of effort required for each project" in the context of Emacs. What "project"s are you talking about?

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.

(I also edit python in emacs regularly, not sure what's changed in the last N years)

I am not sure what you mean by "every tweak" but fwiw:

    $ ls ~/.vim/bundle | wc -l 
    45

    $ wc -l ~/.vimrc 
    401 /home/rahul/.vimrc


    $ vim --startuptime vim.log

    $ ruby -ne 'print if 2..7 or $. == 151' vim.log

    times in msec
    clock   self+sourced   self:  sourced script
    clock   elapsed:              other lines

    000.810  000.810: --- VIM STARTING ---
    217.536  000.003: --- VIM STARTED ---

In a week? 6 years and counting.

Why not, e.g. Racket? If you're going to go the trouble, _get it right_.

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?

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/msg000...