[jbssm]

I wonder if there is any project starting to re-write Emacs according to modern practices like we now have NeoVIM for VIM.

I really like editing in VIM but I moved to Emacs using Spacemacs to try and get the best of both worlds (org mode for scientific research seems a really cool approach).

Still I see Emacs as being quite more bug prone than VIM and VIM than NeoVIm.

Perhaps this is what's needed for someone to start a complete refactor of Emacs and bring it (I mean the code not the editor) to the modern age.

[dmm]

I don't really see that as being the case. Emacs development is very active, even at the low levels. The Guile scheme implementation now has an elisp implementation and there's a good chance that emacs will be moved to it eventually.

If you encounter bugs you should submit bug reports.

[wtbob]

> The Guile scheme implementation now has an elisp implementation and there's a good chance that emacs will be moved to it eventually.

FWIW, I think that's entirely the wrong direction to go. Emacs should be ported to Common Lisp, with an elisp compatibility layer.

Scheme's a neat didactic tool, but anyone who wants to produce production-level software in Lisp should write it in Common Lisp. Heck, even Schemers recognise that, which is why the RnRS controversy exists.

[pmoriarty]

My own view is that Scheme is exactly the right way to go and CL would have been the wrong way to go.

Modern Schemes are fully as production-ready as CL. The view of Scheme as merely an educational tool is outdated, and usually based on limited experience with ancient, bare-bones Scheme implementations such as MIT Scheme.

Modern Schemes like Chicken have fairly extensive collections of practical libraries and features that barebones Scheme implementations lack. To add to that, Scheme is far more elegant than CL, and doesn't contain all of the ancient crud of CL, so is far more pleasant and easy to program in.

I'm not thrilled that Guile (rather than Chicken) is the Scheme of choice for Emacs, but it's a far better choice than CL.

That said, even CL would have been an enormous improvement over elisp. So the sooner the migration from elisp starts (whether to Scheme or CL), the better.

[wtbob]

> Modern Schemes are fully as production-ready as CL.

Modern Scheme still doesn't have hash tables (c.f. R7RS[1]; of course Lisp has them). That, right there, prevents it from being a production-ready language. I could omit the rest of this post and I'd be right.

Scheme does have continuable exceptions, but it's still a far cry from Lisp's conditions and restarts.

Scheme's type system is extraordinarily lightweight. There's no way for the user to define new types, nor even a lightweight way to query for an object's type (unless I've missed something, one must use the various type predicates one-by-one).

Relatedly, there's no way to declare variable or function types; no way to pass that information on to an optimising compiler. There are no compiler macros. Indeed, compilation in general is woefully underspecified.

There's no object-orientation: no classes, no generic functions, none of that. One has to roll one's own if one wishes to.

Although it does have cond-expand, unlike Lisp Scheme doesn't specify READ-SUPRESS which works in conjunction with #+ and #- to skip variant syntax supported by other implementations.

This raises the issue of the reader in general. Scheme's reader is not extensible; it lacks reader macros. It provides no access to the current readtable, or any way to manipulate it.

Scheme doesn't even have a general (i.e., unhygienic) macro facility! Its hygienic macros are sufficient for many use cases, but not all — e.g. anaphoric macros.

Its iteration construct (yes, singular!) is severely limited. There's no general facility like LOOP.

It lacks settable places (this is the capability in Lisp of writing `(setf (getf 'foo bar) 'baz)`).

Scheme does finally have dynamic variables, although they are more unwieldy to use than Lisp's specials.

I do like its well-specified numeric tower.

> Modern Schemes like Chicken have fairly extensive collections of practical libraries and features that barebones Scheme implementations lack.

But they require that for even very basic functionality (like hashtables!). One of Common Lisp's downfalls is having to use implementation-specific functionality; Scheme is worse.

A related problem with Lisp is that Gray streams aren't part of the standard. But Scheme's ports are even less-specified than Lisp's streams.

> To add to that, Scheme is far more elegant than CL, and doesn't contain all of the ancient crud of CL, so is far more pleasant and easy to program in.

You know what I find pleasant? A language which anticipates my needs and my problems, and has already solved them. Time and time again I find that Common Lisp has done exactly that.

I'll certainly admit that there are parts of Lisp I'd change (the default upcasing is hideous; some of the function names are ugly; the varying argument order between similar functions is beyond lame). But I'd never want to use a language which treats NIL as true!

Scheme's not really a toy: it's clay which can be used by thinkers as well as students to play with problems. But it's not suitable for writing portable, high-performance, industrial-strength, real-world problems. Common Lisp is.

[1] http://trac.sacrideo.us/wg/wiki/R7RSHomePage