Hacker News new | past | comments | ask | show | jobs | submit login
My Lisp Experiences and the Development of GNU Emacs (2002) (gnu.org)
177 points by tosh 15 days ago | hide | past | web | favorite | 43 comments



The principle of writing a fast core in C, and choosing a Turing-complete language as the language to build the tool, and further giving the user an interpreter so that (s)he can extend it, is a brilliant design. Whether or not you are a Lisp fan or an Emacs user, this is a great way to build a sophisticated tool.

While the unix tool philosophy is to do one thing and do it well, Emacs shows that it is possible to build software which lasts 50 years by going the other way as well, as long as there is a philosophy of empowering the user.


I've been thinking about the whole Unix philosophy vs Emacs and I'm not sure Emacs does not follow it: according to Wikipedia: 'GNU Emacs, describes it as "the extensible, customizable, self-documenting, real-time display editor"'.

And it does it very well! It just turns out that "extensible, customizable, self-documenting, real-time display editor" is really powerful. Wanna display text in a way that makes it easier to edit code? Evil. Wanna display text so its easy to interact with Git? Magit. Wanna display text so that its easy to navigate your file system? Dired. And so on.

Emacs "just" lets you display and interact with text on your screen, and it does it very well. I didn't think much of text UIs until I used Magit.


Yeah, Emacs follows UNIX philosophy only in the edge case of "doing one thing" being doing everything that's even tangentially related to or representable as text. It technically conforms, but kind of goes against the spirit :).

Emacs is really best seen as a platform for running Emacs Lisp software. An OS within an OS. It just happens it's optimized for text editing, and it ships by default with a text editor.


On the other hand, don't look at emacs as a tool on Unix, look at it as a tool like Unix... it has a few simple abstractions (text, buffers, windows) and presents to the User a programmable shell to act on those abstractions.


>Yeah, Emacs follows UNIX philosophy only in the edge case of "doing one thing" being doing everything that's even tangentially related to or representable as tex.

I think that is the right idea, but it can be reworded to:

>Yeah, Emacs follows UNIX philosophy only in the case of "doing one thing" by being an interactive, turing complete, generic text processor.


In short: Emacs runs elisp and does it well.


Agreed. One of the pillars of Unix philosophy is stdin/out and pipes. Emacs balatantly ignores them.


If it didn't ignore them, how would it use them and what would it be able to do better? Genuine question.


Does any GUI application follow the Unix philosophy very well? Because the other side of "do one thing and do it well" is that arbitrary tools can be combined, and that tends to break down once you leave the command line.

Emacs tries to work with the command line; it can run a terminal inside it, or run commands on a buffer with M-|. And emacsclient --eval can run a Elisp from the terminal. But...

> Wanna display text so its easy to interact with Git? Magit. Wanna display text so that its easy to navigate your file system? Dired.

That nicely highlights the way Emacs usually interacts: by wrapping existing tools rather clumsily with a lot of Elisp.

And it's forced to do this because the other Unix philosophy of "everything is a file" has made it very difficult to evolve beyond the command line.

Which is not to say Unix was wrong: the command line is very good at what it does and lots of other schemes following it have crashed and burned because "do one thing and do it well" often conflicts with their more complex notion of "everything is an X".


> by wrapping existing tools

So you propose emacs should write it's own version of everything, instead of using existing functionality?

> rather clumsily

That's a highly subjective view, if not weasel words.

> with a lot of Elisp.

How does the amount of lisp even matter so long as it gets the job done well?

Anyway, dired's great (in your view where does it fall short - honest question) and while I've never used magit I've heard not a single bad word against it.


> Does any GUI application follow the Unix philosophy very well? Because the other side of "do one thing and do it well" is that arbitrary tools can be combined, and that tends to break down once you leave the command line.

Building scriptable applications works relatively well: see OSA on macOS.


It's funny that you should call magit "clumsy", implicitly opposing it to Git's CLI.


I'm waiting for the day when somebody writes a Neovim frontend in Emacs, so I can literally use Vim from inside Emacs.


In the days when I used an embedded terminal in emacs (adcii term or something, I can't quite recall), I at one point used vim to open a filw in that terminal, and lo and behold, it actually functioned pretty well. So I finished editing the file and then realized what I'd just done and spent the rest of the day laughing! (:


You can already almost use Vim from inside Emacs via Evil mode.


What of vim are you missing from Emacs' Evil mode?


That's basically the approach used by web browsers, too. (JavaScript even has a Symbol type now!) This architecture has long been an under-appreciated aspect of the Lisp way.

On the internet, I often hear programmers talk about how great the Unix philosophy is, but hardly anybody follows it any more. They may not be using s-exps but everybody is building their programs around the Lisp philosophy.

Pulling open a live inspector, digging into rich data structures, and running interpreted ad-hoc code? That's not exactly Unix you're practicing.


> programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

This seems important.


> The war that Symbolics started was what wiped out MIT, but there were other events going on then. There were people giving up on cooperation, and together this wiped out the community and there wasn't much left.

The internal struggle in the MIT AT Lab due to Lisp and Symbolics seems more interesting than I thought. I read Wikipedia, and it says "there were two AI Lab people who choose not to be employed by either: Richard Stallman and Marvin Minsky". Wow, I never expected to see these two names in the same line.

Are there any good book that covers this part of the history and its connection to the later development of free software movement?


Dan Weinreb had a different take on the symbolics era and the MIT lab.

[1]: https://danluu.com/symbolics-lisp-machines/


Thanks for the link - that puts quite a different perspective on those events. I had the luck to get to know Dan Weinreb during the International Lisp Conference 2009 in Boston - great guy.

It should be too surprising as it took place at the MIT, but many of the founders of Lisp were present. Dan, Guy Steele, Richard Gabriel, JonL White, and so many more. It was really inspiring.

Interestingly, though the ILC is a conference about all flavous of Lisp and its applications, RMS wasn't attending the conference.


I was at an Emacs Lisp introduction course given by Richard Stallman, at some ILC.


All I can see is a man pathetically trying to justify himself, and failing.


To some degree, Levy's "Hackers: Heroes of the Computer Revolution" (1984) covers this, but probably not to the detail you want. He has a whole chapter on Stallman and the AI Lab. Of course a problem was that in 1984 the modern importance of free software wasn't really apparent. Stallman looks principled in the book but sort of a fool because it looked like the people who went to industry would become rich and Stallman's "GNU" project looked like the impractical utopian dreams of an aging hippie, not the source of software used in millions of computers (and other devices not even thought of yet) in the future.


> Of course a problem was that in 1984 the modern importance of free software wasn't really apparent.

Perhaps it wasn't apparent widely, but it was certainly clear to MSFT and IBM. IBM lawyers at the time refused to allow RMS to come speak at the Watson lab where I worked, because of his ideas about free software.


Too bad GuileEmacs[1] project didn't take off. On the other hand, there is an Emacs rewrite in Rust[2].

[1] https://www.emacswiki.org/emacs/GuileEmacs

[2] https://github.com/remacs/remacs


[1] is, as you mention, going nowhere and with good reason (Guile is pretty much a single person project at this point and no heavy hitter from the emacs-devel community is interested in it).

[2] is also going nowhere since again no Emacs core developer is interested in it and to top it off, they’re well on the path to creating something even more complicated and harder to understand than Emacs’s C core.

These are _good_ developments since GNU Emacs is progressing rapidly on its own merits.


There's also lem, which is a Common Lisp based Emacs clone https://github.com/cxxxr/lem


Looks like that project is flirting with porting it to Electron. Too bad, an emacs-like editor in Common Lisp would have been cool but I'd like to be able to run my editor plus some other programs. Not sure I have enough memory for more than two or three Electron apps.


The standard curses version isn't electron at all, though.


Yeah but flirting with Electron is a strong indicator that the project is pathological in its decision-making, to me anyways.


It's more of a statement on the state of Free (as in speech or beer) graphics frameworks in common lisp IMO.


There's an OpenGL port already.


Edwin is an Emacs in MIT (now GNU) Scheme.


Having spent some serious time in TECO while writing a compiler in Bliss 36, I could not agree more with It was our text editor, and was an extremely ugly programming language, as ugly as could possibly be.


TECO is notably more tractable than Malbolge.



Off topic, but I wonder if Stallman regrets that the FSF team didn't develop a working kernel for GNU early in the history of the project, perhaps at the same time as the development of GCC? The existence of a GNU kernel would have obviated the bundling of Linux with GNU user space software.


Linux could not have been made by GNU early on, if for no other reason than it was not obvious that the 386 based PC was going to be the dominant platform even in 1991 when Linus started the project.

Making a portable OS kernel is a much larger project than making a non-portable kernel, and the focus on 386 based PCs allowed for getting something useful up and running quickly.


I suppose if you are looking at the "workstation" tier, the humble 386 was not an obvious choice... Most workstations (i.e. NeXT, Sun, IBM, SGI) already had a Unix based OS, so likely creating another one wouldn't have been as fun. 386 boxes came with DOS or Windows... and it Unix was $tupid expensive.

The 386 was a runaway winner, and it was pretty clear from the day Compaq released the first 386 powered PC that 386 was the future. It allowed virtualization of 8086 apps (so you could multitask with existing software, which was a huge selling point at the time). It had virtual memory, a critical feature when lots of RAM was 4MB. It also had preemptive multitasking and allowed you to have a flat memory model (even though the 386 memory model was segmented). All the things you need to make a really nice Unix like OS.

Other options were either an order of magnitude less popular (i.e. use Motorola 68030 based computer) or technically limiting (use a 286 based PC which had some brutal limitations with memory access).


Minix ran on both 68k and 286 based machines before Linux was started. Minix ran on the 8088 even.

IIRC Linus specified the features of the 386 that you mention as being a reason for not just porting Minix; Minix wanted to be system agnostic so would not easily be made to be performant on the i386.

IMO, focusing on a single system allowed for rapid development of features, and as you say the 386 was not an obvious choice for "workstations" which is probably where RMS was thinking.


A comment in OP mentioned Readable Lisp S-Expressions: https://sourceforge.net/p/readable/wiki/Solution/


why no german version?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: