
My Lisp Experiences and the Development of GNU Emacs (2002) - tosh
https://www.gnu.org/gnu/rms-lisp.html
======
sn41
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.

~~~
globuous
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.

~~~
TeMPOraL
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.

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

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

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

------
bcaa7f3a8bbc
> _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?

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

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

~~~
_ph_
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.

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

------
xvilka
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](https://www.emacswiki.org/emacs/GuileEmacs)

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

~~~
jhbadger
There's also lem, which is a Common Lisp based Emacs clone
[https://github.com/cxxxr/lem](https://github.com/cxxxr/lem)

~~~
na85
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.

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

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

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

------
wglb
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._

~~~
kragen
TECO is notably more tractable than Malbolge.

------
cenanozen
Found the video:

[https://www.youtube.com/watch?v=4Jjhmc3Txv0](https://www.youtube.com/watch?v=4Jjhmc3Txv0)

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

~~~
aidenn0
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.

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

~~~
aidenn0
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.

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

------
ngcc_hk
why no german version?

