Julian Fitzell <julian at beta4.com> wrote:
	I keep reading words to the effect of "people can just strip out what 
	they don't want".  But, no, we can't because we don't know where one 
	thing starts and the other ends.  If stripping everything out was so 
	easy, then this process that is taking months and months would already 
	be done.  I don't want to go through this 
	many-month-long-for-many-people process by myself every time I need to 
	strip down a clean image.  People who know what they're doing need to 
	carve up the packages so Joe Average doesn't have to.
	
I'm reminded of Interlisp.  More years ago than I care to remember,
I got my hands on the Interlisp sources (before it was Interlisp-D).
There wasn't any question of porting it, I just wanted to improve an
existing Lisp system (which was, IIRC, based on a very old BBN-Lisp
version).  So I sat down with the listing and started pulling.  Turned
out there was hardly anything I could extract beyond a few basic
list processing things like APPEND and REVERSE, because everything was
connected to everything else.  Someone at Xerox (I can no longer recall
who, so if you were the person and you're reading this list, thank you
very much because it really WAS helpful) sent me a report they'd done
on the Interlisp "kernel" (because they had faced the same problem).
The "kernel" was quite large and contained some surprises...

Carving up something that wasn't designed that way in the first place is
darned hard, and I don't expect the work to be finished any time soon.
BUT it is going to pay off in two ways that are helpful to ALL Squeakers:

(1) It will make the sources easier to search.
    We talk about how great it is to have access to all the sources,
    but that's the problem with the monolithic system, you have ALL
    the sources.  When you are trying to learn some aspect of the
    system, the others get in the way.  (I have tried to learn Morphic
    from the sources and failed.  I have high hopes of doing better
    with after the MCP people have done their job.)

(2) It will make debugging easier.  Construct the minimal system that
    exhibits the bug, and you have eliminated a _huge_ amount of code
    which you know doesn't contain the bug.  Oh, most bugs aren't that
    hard to find, but for the ones that are, it can help.  (If you
    think that using the MessageTracer to focus your attention on the
    messages that might contribute to the bug would be a bigger help,
    you're right.  But those messages might use class or pool variables
    that might have been affected by code in a package that you had
    used but not during the test where the bug showed up.)