[no subject]

Our user needs the functionality in Lib-A and in Lib-B.
Lib-A needs Lib-C1.0, but lib-B needs lib-c1.1.

There are lots of variations on this theme. As there gets to be lots
of libraries, the problems start to compound, because then people
make meta-libraries containing version 1.1 of lib-a and version 1.2 of lib-b,
etc. Then 2 meta-libraries overlay enough to kill each other and one doesn't run 
in anything less than system 7.1 whereas another needs 7.0, etc.  The libraries 
come from different vendors so they're always out of sync with each other & the 
operating system, etc.

Yes CL is too big. But its at least self-consistent and complete enough not to 
require lots of libraries. 
I like the idea that Dylan started out with a small lisp. 
Now decide when the middle of Dylan's
life cycle will be and how many megabytes will be on a $4 RAM chip that year.
[Hint, a 64Mbit chip has already been prototyped.]
If $4 is too much, think about how much software costs, and what percentage of a 
product it will be compared to the hardware as hardware costs continue to fall
faster than software costs.

Its ok with me if my toaster has an EVAL in it that is never called. 
Toaster's aren't exactly materially efficient either. If 90% of the code is
wasted, big deal. 


Is C's "Standard IO lib" as standard as everyone would hope? 
I bet not, and it has a LOT less functionality than CL I/O.