3 ms·
I've used full Emacs and Emacs style editors (mg, jove, epsilon) for over 40 years and programmed in LISP for longer than that. In the 1990's it was evident tha
by todd8 5y ago
I've used full Emacs and Emacs style editors (mg, jove, epsilon) for over 40 years and programmed in LISP for longer than that. In the 1990's it was evident that Emacs was in decline.
For a couple of years, I used Vi because IBM's lawyers were afraid of the GPL; during that time I found Vi to be a superior text editor than Emacs. Sometime in the late 80's, Emacs and the GPL were accepted by IBM's planners, and I switched back to Emacs. Quite a few of the AIX kernel developers did end up using Emacs, even though Vi had its advantages as a text editor. It was the customizability of Emacs and the ecosystem of high quality packages that drew me back to Emacs. (For example, a developer on my team wrote the tower of Hanoi command. Try it out: M-x hanoi). Emacs became a general purpose tool for interfacing with your system. With Emacs, I didn't need a graphical terminal to work with multiple windows, I didn't need Norton Commander to have a powerful, portable interface to directory management. It has incredible outliner, mode for LaTeX, interface to git, etc., etc.
My point is that it wasn't the text editing (Vi handled that better), it was everything else, and that everything else was enabled by Stallman's brilliant insight that the editor should be built around a powerful interpreted language, LISP.
LISP was key to the success of Emacs. In the 1980's, people were excited about LISP; by the 1990's the excitement was wearing off. The LISP Machine companies weren't commercial successes. While some LISP compiler/interpreters performed well, Emacs Lisp was simply adequate. In CS programs, Scheme was being taught instead of the more fully featured LISP--Scheme has a simpler tighter core of fundamental features and consequently was a better choice for the ubiquitous undergrad Programming Language smorgasbord courses.
I needed an embedded interpreter to be a key part of a distributed network of servers I was designing. LISP was my choice, but my companies own, very experienced, developers rebelled. Smalltalk, Prolog, and even building our own C-based language interpreter were all viewed as more acceptable than LISP.
The way to make Emacs more popular isn't to persuade people that they want a customizable editor that requires a great deal of LISP expertise. That just won't happen. Pick a language from the one of the top 15 languages and allow Emacs customizations to be developed in one of these languages. Here's one measure of the 15 most popular languages[1]: Python, Java, Javascript, C#, C/C++, PHP, R, Objective-C, Swift, Typescript, Kotlin, Matlab, Go, VBA, Rust.
Out of the 15 languages listed above, many can be disqualified for obvious reasons: R and Matlab are not general purpose enough, Rust is far from interpreted and has a slow compiler, and so on. In my opinion, Emacs would be more popular if its core supported Python or Javascript or even Go (say running in a separately compiled process that interacted with the Emacs server via IPC). I'm not a Javascript person, but Javascript is likely the best solution; I would gladly take the time to learn how to use it for Emacs configuration and customization. If Emacs was customizable in Javascript, there would be an army of developers working with it.
[1] https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html
- jimmyvalmer 5y agoI was nodding along to your recount until your recommendation for a new extension language. It wasn't your selection of language that rankled so much as the cavalier manner in which you suggest it. Replacing elisp with, say, javascript is tantamount to rewriting nearly all of emacs, a product of 40 years (although presumably fewer man-years).
- todd8 5y agoI agree with you that replacing all of the eLisp with say JavaScript would be impractical because there are hundred thousands of lines of eLisp that would have to be replaced, but Emacs is never going to increase its appeal while requiring new users to learn its own, somewhat peculiar, extension language. Emacs out of the box is usable, but not as good as JetBrains tools or VS Code or Vim. Emacs is worth learning because it is an incredibly flexible editor construction kit that can be shaped into the editor one desires, but this, unfortunately, can require the user to write dozens of lines or even thousands of lines of configuration in eLisp. The young programmers that I know are just not going to bother to learn eLisp to get their mode line to look useful. Spacemacs and Doom are good examples of how far one can push Emacs configurations, but even working with these prebuilt advanced configurations requires some delving into eLisp. One approach to replacing eLisp would be to write a tool that compiles eLisp into JavaScript. eLisp has enough idiosyncrasies that this will be very challenging, but perhaps this could work. There are so many JavaScript programmers that could help with cleaning up the inevitable broken packages. Alternatively, like the NeoVim project, most of Emacs internals could be left in place and a JavaScript extension language could be added so that new packages could be written in either eLisp or JavaScript. Someone would have to figure out interoperability between the two—sharing data between two interpreters each with different garbage collectors for example. LaTeX faced a similar problem. The TeX esoteric macro capability was used to build LaTeX and LaTeX was used to build hundreds of complex packages to be used with LaTeX. The TeX/LaTeX world moves at a snail’s pace compared to Emacs, but they have made gradual progress in modernizing TeX and LaTeX (LuaTeX, LaTeX3, ConTeX, etc.)
- jimmyvalmer 5y ago