

My Lisp Experiences and the Development of GNU Emacs - octopus
http://www.gnu.org/gnu/rms-lisp.html?

======
CoreDumpling
_The interpreter we wrote in that actually wasn't written for Emacs, it was
written for TECO. It was our text editor, and was an extremely ugly
programming language, as ugly as could possibly be._

For proof, see the source code here: [http://pdp-10.trailing-
edge.com/mit_emacs_170_teco_1220/inde...](http://pdp-10.trailing-
edge.com/mit_emacs_170_teco_1220/index.html)

It is certainly heavily annotated for good reason.

~~~
derleth
TECO was so ugly because the command language and the programming language
were the same thing: You programmed TECO by entering the same commands you
used to do editing with it, and those commands were both terse and made heavy
use of control characters.

On the other hand, it was also a high-level programming language with native
support for strings and regular expressions and, of course, the editor
qualified as an interactive interpreter. TECO-the-language actually got
reasonably popular within the communities that used it as an editor,
especially the ones that had the more advanced TECO variants with all the
bells and whistles.

~~~
nochiel
Here's a relevant article by MarkCC (PhD, Google), on "The Glorious Horror of
TECO". [http://scientopia.org/blogs/goodmath/2010/11/30/the-
glorious...](http://scientopia.org/blogs/goodmath/2010/11/30/the-glorious-
horror-of-teco/)

------
IvarTJ
_Once I stopped punishing Symbolics, I had to figure out what to do next. I
had to make a free operating system, that was clear — the only way that people
could work together and share was with a free operating system._

 _At first, I thought of making a Lisp-based system, but I realized that
wouldn't be a good idea technically. To have something like the Lisp machine
system, you needed special purpose microcode. That's what made it possible to
run programs as fast as other computers would run their programs and still get
the benefit of typechecking. Without that, you would be reduced to something
like the Lisp compilers for other machines. The programs would be faster, but
unstable. Now that's okay if you're running one program on a timesharing
system — if one program crashes, that's not a disaster, that's something your
program occasionally does. But that didn't make it good for writing the
operating system in, so I rejected the idea of making a system like the Lisp
machine._

Is this something that is still relevant to modern attempts at making a Lisp
operating system?

~~~
hvs
No. Actually, the reverse of that was one of the reasons why the Lisp Machines
(<http://en.wikipedia.org/wiki/Lisp_machine>) ultimately failed (among
others): commodity hardware could run Lisp as fast or faster than custom
hardware.

Nowadays, the hardware doesn't limit the creation of a Lisp OS, but many other
things do. 1) Getting people that want to do the work
(<http://linuxfinances.info/info/lisposes.html>) 2) The fact that you can run
perfectly good Lisp implementations on top of general purpose OSs
significantly decreases the need for a Lisp OS. 3) Lisp isn't as popular as it
once was (or should be :)

<http://lists.tunes.org/mailman/listinfo/lispos/>

