A successful lisp machine?

Thomas Fischbacher tf@another.gun.de
Wed, 30 Apr 1997 16:12:18 +0200

Harvey wrote:

lr> I don't want to have to reboot my lisp machine into native
lr> linux mode just because I want to run xv or xsced or The gimp, or all
lr> the other cool software that others are writing.

As long as there's a lack of software, a LISP machine certainly is most
useful only if there's another Unix machine standing beside / wired to it.

I wouldn't sacrifice a clean aproach for the sake of existing software.
That's what Intel/Micro$oft do. Look: x86s still have to handle
self-modifying code.

lr>    2. Write a loadable kernel module and/or the kernel patches needed
lr>       so that the lisp side doesn't have to fight the operating system.

The question is: what does the kernel have to do?

DOS:       "file subsystem"

UNIX:       file subsystem + process subsystem

LISP-OS:    file subsystem + process subsystem + function subsystem ?

lr>    3. Keep the system unix compatible so that people can do C hacking
lr>       & can use C apps at the same time as their lisp machine.

No! This would be a big mistake.

Wherever possible, keep it simple, keep it small, keep it free from
bad influences. :)

lr> If this isn't done, then what I'm afraid will happen is that even if a
lr> wonderful lisp machine is developed, the unwashed masses still won't
lr> be able to use it as their primary operating system.

My opinion is:

UNIX is a good, stable, useful, reliable operating system with one
very important problem: it's extremely difficult to master.

In order to become a UNIX wizard, you have to learn sh, awk, perl, make,
C, EMACS, tcl, and some more. That's seven very different programming
languages! (Not to mention what you have to know about config files,
other utilities, program options and non-Unix-specific languages like

Certainly, _we_ mastered all that, but you can't expect it from the average
user, or even programmer. Every Unix system needs someone with at least
rudimentary admin knowledge. Therefore, you won't find BSD on Joe User's
machine at his home.

Furthermore, you don't have access to full computing power from within
sh/tcl/perl/...; another annoying problem is that you often have to do
very complicated things to extract the important pieces of information
out of the output of a program. And as soon as you have successfully
parsed a program's output and then processed it, you are about to
flatten it to an unwieldy stream of characters again.

You know the saying
"Some people who have a problem say 'we can use awk for it' and at once
they have two"?

lr> All that was needed really was the kernel.  Not that this wasn't a lot
lr> of work, but it was a *hell* of a lot *less* work than writing
lr> everything from scratch.  And, because so much was already available,
lr> a lot of people became excited about the whole endeavor, and added
lr> device drivers for their hardware, and other hardware, etc.

Yes, right, but why do we want a LISP machine? To run existing UNIX
software on it? Hope not!

I spend much too much time and energy moving data between the following
programs/languages: awk, gnuplot, postscript, TeX, EMACS, perl (and some
more). This is the main reason why I think a LISP machine with quite some
programs substituted by function libraries will be much more useful
than UNIX.

By the way, why is EMACS so successful? Mainly because you can read mail
with it, write programs and all other sorts of text, ftp, use it as a
calculator, day planer, directory browser, etc. and don't have to worry
about how to get and process the output from other programs. And it's
easily extensible.

lr> For this whole LispOS project to succeed, I think it should leverage
lr> as much as possible off of existing systems.  This would mean that it
lr> should run on top of Linux or FreeBSD (preferably both) as much as
lr> possible, and it should run on top of MS Windows if possible.  It'd be
lr> great if it could also run on Java systems, since they're becoming so
lr> popular.

As long as it's neccessary, let it run on top of some specific UNIX
kernel. Needn't even be multiple different kernels. I see absolutely no
point in trying to run it inside Windows, System7, OS/2, or Java.

lr> can't afford to reboot every time they need to run TeX.

If you have a closer look, TeX is quite horrible.
Certainly, it's often much more useful than a typical WYSIWYG (WYGIWYD?)
word processor, but look closely: TeX is a very very primitive macro
programming language. Another language. And what an unwieldy one.
It's extremely difficult to make TeX do more complex things.

I'd prefer a small LISP package providing basic typesetting functions.

regards,            Thomas Fischbacher   tf@another.gun.de