Re: MCL size/distribution (was: MCL support for MOP)

[Repenning Alexander <ralex@tigger.cs.colorado.edu>]

Subject: Re: MCL size/distribution (was: MCL support for MOP)
                                                                 
>We'll probably be                                             
>looking into a few ways to reduce the size of MCL (though probably
>not for 2.1).                                     
>1) A tree shaker..
>2) Make the development environment be optional..
>3) One or more shared libraries..

Many systems have gone (or like to go) trough the following stages:

a) Prototype
b) Testing: Public Domain application
c) commercial application

MCL is certainly a great (if not the best) product addressing stage (a). It 
is a great environment to prototype things. 

In stage (b) things already become a bit more problematical. A 1.5 MB
"hello world" despite todays improved technology doesn't fly over the
internet. As a source for pre- commercial user testing the internet is
an in-valuable source. However, with a memory demand starting at about
1.5 MB this is tricky - or lets just say impossible. That is, the size
of your applications has an enormous impact on the testing stage.

Stage (c) is even more problematic. Something Lisp users get to hear
quite often is "you did a great prototype in Lisp now lets implement
the application in C." This is frustrating! If my plan is to go on
from stage (a) I don't like to loose all or more of the time I saved
using MCL by strarting from scratch with C or C++ (please no
programming language flames). Lisp has great potential of not only
being a tool to prototype but also to maintain and extend
applications. I like to have a Lisp tools that supports stages a-c and
I don't like to be considered a fool (by non-lisp programmers) for
using Lisp to do so.

One could argue that these concerns are only temporary since RAM size
is growing exponential, the price of RAM is decreasing, etc. This is
only of litte comfort for users since they will always compare things
to existing high-functionality applications like Word. After all,
these applications probably have been created by companies like MS
using quite powerfull programming environments as well. All I'm saying
here is that you cannot justify extreemly large applications with
powerfull programming environments.  Switching the environment is not
an option for me (I rather change my profession). Therefore, I can
only hope that the MCL team appreciates a A-C market.


A GOOD tree shaker would be my favorite. In addition to ordinary tree
shaking it should allow me to explicitely keep/remove entities like
symbols, documentation strings, file references, macro functions, and
entire modules (e.g., compiler, editor, etc). The interface to the
tree shaker should be simple. If I need to "click around" for an hour
it's no good. I could imagine a bunch of keyword added to
save-application (e.g., :shake-tree-p, :strip-documentation-strings,
:keep-symbols (..) , strip-symbols (..)). That's maybe a bit naive,
but you get the idea.

>2) Make the development environment be optional..

Could this be part of the shaker?

>3) One or more shared libraries..

This would help me to keep a large number of applications - which I
don't.  Also this fragments my application -> more files -> increased
user confusion.

So many demands, so little time ..

  Alex Repenning
  University of Colorado at Boulder