MCL in Academia (was: applications sizes, tree shakers, and

[ralex@cs.colorado.edu (Alex)]

In article <9503201438.AA13226@herald.usask.ca>
montbrj@herald.usask.ca writes about the size of MCL and Dylan:

> 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..


Being in academia these days is a different ball game. MCL, and Lisp in
general, is not exactly the programming language of choice. Funding
programs (NSF, ARPA) expect more and more usable stuff. For instance,
in education we are using MCL to create interactive learning
applications. People, this is tough. We keep on going to schools and
install applications implemented in MCL on their machines. For our
Remote Exploratorium we end up running NetScape and Agentsheets (an MCL
application) on the same machine on 4 MB Mac 475s using virtual memory.
This is hellishly slow!

MCL folks, don't make us switch to C. Here at CU, we are really scared
of MCL 3.0 because all these great new goodies may use up valuable
space. A critical size constraint is that we need to be able to put our
application (in compressed form) onto a 1.4 MB floppy. I think right
now we have about 70 kB space left. When we talk to teachers or other
kind of users we can't say "sorry, it doesn't fit on a floppy anymore
but hey it really has an improved Lisp inspector.." They don't care
about these things.

MCL is in a great position for applications such as educational
environmetns because it features incremental compilation which is
really great when you create helper applications for netscape to send
things like agents around. In order to benefit from this situation it
is not good enough to hope that future Macs will ship with more memory.
New strategies need to be found to deal with the size problem. For
instance, some of the built in tools such as inspectors, etc. should
maybe ship as part of the library that can be loaded for the
application designer but is then left out of the application image
created for the end user.

If MCL 3.0 is any bigger than MCL 2.0 we probably wont be able to use
it. I believe the strategy should be to at least keep the size of MCL
constant. Eventually Microsoft products will become so big (see Word
6.0) that MCL at its current and constant size will become a very
reasonable programming environment for the rest of the world.

Bottom line: we REALLY, REALLY care about SIZE!

   Alex



     _/_/_/    _/_/_/  _/_/_/    Alexander Repenning
   _/      _/    _/      _/      University of Colorado
  _/            _/      _/       Department of Computer Science and
 _/            _/      _/        Center of LifeLong Learning and Design
_/      _/    _/      _/         Boulder, CO 80309-0430
 _/_/_/        _/_/_/            Phone: (303) 492-1349, Fax: (303)
492-2844 
Email: ralex@cs.colorado.edu
http://www.cs.colorado.edu/homes/ralex/public_html/Home.html