As an
extension language for a
text editor,
Emacs Lisp shines. It really is a
Lisp, so very sophisticated concepts may be clearly coded.
Unfortunately, as a Lisp, Emacs Lisp is nothing short of horrible. It's an antiquated variant, nothing like any modern Lisp. The worst failing is probably the use of dynamic binding for all variables. Both Scheme and Common Lisp use lexical binding. This is much easier to understand, easier to implement efficiently, and far more expressive. For the (few) cases where dynamic binding is useful (and these do occur in text editors, especially with regard to global variables holding various "states"), constructs like (fluid-let ...) can be used in any modern Lisp.
And don't get me started on compilation. Why are we using a Lisp with byte compilation, when excellent Lisp compilers exist? These can produce native code, and you can freely mix native compiled code, byte-compiled code, and interpreted code. But instead, Emacs uses its own Lisp, so it has to use its own compiler.
But Emacs Lisp is none of that. So it cannot be made threaded. So every time your Gnus is scanning for new news, the rest of Emacs is unusable. And programming major modes is made considerably harder.
The ideal situation would be a rewrite of Emacs in Common Lisp; I believe Erik Naggum has proposed this, and is working towards it. Of course, nobody wants to lose all the Emacs Lisp code floating out there. So a module allowing execution of Emacs Lisp is essential in any such endeavour.
This is the way ahead for us; unfortunately, it is way ahead of us.