Benevolent Dictatorship

[Harvey J. Stein]

Lyn A Headley <laheadle@midway.uchicago.edu> 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
   http://sagan.earthspace.net/~esr/writings/cathedral-bazaar/) will
   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
coding...

-- 
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il