applications sizes, tree shakers, and the like...

[montbrj@herald.usask.ca]

A perfect example:

>>-> +-------------------------------------------------------------+
>>-> | These demos are on develop CD #21. The 'hello' application  |
>>-> | is 56K on disk, it has to load the Dylan framework which is |
>>-> | 524K, the main Dylan library 465K, the mac toolbox library  |
>>-> | which is 57K. Time from double clicking the hello           |
>>-> | application on the hard disk (I copied it all to the HD     |
>>-> | from the CD before running it) until 'Hello, Dylan!'        |
>>-> | appears is 22 seconds on a PowerMac 8100/80. When looking   |
>>-> | at 'About this Macintosh' in the Finder it reveals that     |
>>-> | 'hello' is running in a 2000K partition which is about 75%  |
>>-> | full. The README states that all this will be improved      |
>>-> | upon, so who knows what will be. --- james mccartney        |
>>-> +-------------------------------------------------------------+

As I recall, but when apple first acquired the mcl product they were
making similar promises about the size.. (I've posted references and
quotes for this statement in this list before, if you really care,
look them up yourself). you know, yeah yeah, size is a big priority,
and right now we have top engineers employed finding ways we can make
you happy.  well, forget it, two years later they came out with a
program 2 times as big as the original that wouldn't even fit on a
floppy disk.  I'm really hoping, and I think this is their only
practical option, that future implementors of mcl/dylan look at using
the shared library manager to stash most of the guts in shared libraries
to maintain practical application sizes.  my question is:  if they're
not looking at this, then what the hell are they doing?  we're all
in the business of making programs and getting them to market, we don't
want a white elephant.



the present state of convenient excuses (one's I've seen in response to my
complaints about mcl application sizes):

well, other lisps are really big, so ours is too!

most lisp users, people in the academic community, don't give a dam
about the real world anyways...

some day soon, not too far away, everybody will have lots of memory
and won't you feel stupid then for complaining now...

only people with 'big' machines should use lisp programs

no, we didn't promise anything about making mcl smaller, saying it's
a priority is not the same as making a promise..



don't get me wrong, mcl is an excellent product and I'd like to use it
myself, as I had hoped to when I purchased it a few years back, for
making commercial programs.  At the time when I purchased the product
the only literature available mentioned apx. 700k app sizes for stand
alone executable with promises about how reducing this size was a 'big
priority'.  imagine my surprise when I opened the box and the smallest
stand alone I could make was 1.3 megs?

please do not reply to me about lisp application sizes, I am well aware
of the issues here.  if you'd like to do something useful, why not send
a note of encouragement to digitool asking them to look into the possibility
of using the shared library manager, or something like that.

AtDhVaAnNkCsE

-john