Harvey J. Stein
20 Mar 1998 17:23:24 +0300
Lyn A Headley <email@example.com> writes:
> Kragen> I suggest another way: a sort of economy, like Linux.
> This is a pretty pragmatic approach, and it leads to a proliferation
> of code, which is pretty cool, but it sure as hell doesn't lead to an
> elegant system. Rather, it leads to something about as elegant as
> Linux. I think it's critical that we *do not* start writing code yet.
I disagree on several points here (and in the related discussions):
1. Yes, in that Linux is unix, Linux isn't elegant. However, it's
very elegant given the constraints, namely that it be unix and that
it be coded in C. In other words, much of the particulars of the
implementation are very elegant. The Linux kernel hackers work
very hard to do it the "right" way. The code tends to be clever
and extremely efficient. They rewrite large swaths of it when it
turns out that it should have been done differently. They reject
kernel changes that aren't done "correctly", or that "shouldn't" be
in the kernel. This has yielded a fast, robust kernel with lots of
functionality early on. The only downside has been the regular
proliferation of incompatible systems (moving from a.out to ELF, &
from libc to glibc, where in both cases it was a good idea to
recompile everything, and periodic kernel changes which require
certain binaries to be recompiled). However, the headaches of such
changes can be largely mitigated for the average user by upgrading
the system less frequently and by using one of the CD distributions
(such as RedHat or Debian) to do complete upgrades.
2. I don't think that this is a special case. I think that using the
Linux approach (also known as the Bazaar approach, see
more likely yield good results than bad results.
One reason a LispOs developed in this fashon will be good is that
there will be people who like it, and like working on it. Any
section of code that is badly designed will eventually hamper
general development.At that point, one or more of the people who is
dedicated to the system will take it upon themselves to rewrite it
properly. Sure, there will always be poor sections laying around,
but they'll all eventually be replaced when they become too much of
a burden. In the mean time, at least the functionality existed.
At least with the functionality in place the system can be
used. That's a lot better than waiting around for a system while
people thrash out the details.
Another reason why the Bazaar approach works is that it's easier to
see what's wrong and what's right from a working model than from a
design spec. With the functionality in place it's easier to try
different things and see what works. Code often makes it or breaks
it based on low level particular details, details which are very
hard to fully enumerate when developing a design spec. Having a
working implementation in which to experiment and try different
things is a major advantage. I'd contend that hacking up something
that works & then rewriting sections that were done incorrectly
will yield a well designed system faster than devloping a spec and
then coding to the spec.
3. On the other hand, the Linux people did have a spec - namely the
unix interface & the posix specs, etc. They also had a lot of
preexisting artwork. Thus, I'd suggest that someone just start
cloning a lisp machine - any lisp machine, in any way shape or
form. This at least in some sense gives a high level spec. Once
it's cloned it can be ported to other hardware, lisp compilers, and
other substrates (i.e. - Flux vs Linux vs Hurd vs bare metal),
redone "correctly", etc. Given all the discussion about how to do
things here, it's clear that it won't be clear how to do things and
what things are feasable, convenient, etc, until we have something
to work with.
4. Working by consensus will obviously not work - it will just take
too long to come to agreement on each design point, and some design
points will never be agreed upon. It would be better to just code.
That's not to say that design points shouldn't be discussed.
However, the discussion will be much more productive if it's of the
form "Any ideas how I should code this component", or "Here's a
patch for fixing component X", etc, than when it sounds like "A
LispOs shouldn't have a file system", or "We have to use
cmucl/rscheme/acl on top of Flux/Linux/the bare metal".
In other words, people need to put their money where their mouth
is. If you want something, then code it. Trying to get someone
else to code it a certain way for you is ... well, I was going to
say "self righteous and arrogant", but I didn't want to say
something that strong, and I can't think of a milder way of saying
it, but that's the idea.
5. A benevolent dictatorship is ok, in that different people would
mostly be in charge of different components, but it needs to be
based on who's doing the coding. If you code a section, then
you're in charge of the section until you give it up or until
someone else does a better job on it, where "better job" is defined
by people using the system using your implementation instead of the
stock implementation. This has happened with large sections of the
Linux kernel over & over again. Maybe it's not so much a
benevolent dictatorship as it is a coding meritocracy.
That's way too much rambling for now. I just hope someone starts
Harvey J. Stein
Berger Financial Research