NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/lisp/mcl/1966

Internet Message Format | 1993-01-11 | 1.7 KB

Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!usc!cs.utexas.edu!sun-barr!olivea!apple!goofy!cambridge.apple.com![e-mail]
From: [e-mail]
Newsgroups: comp.lang.lisp.mcl
Subject: Re: MCL support for MOP
Message-ID: <[e-mail]>
Date: 10 Jan 93 08:36:49 GMT
Sender: [e-mail]
Lines: 25
Approved: [e-mail].C0M

Bill:
> Feedback please. Do you need these facilities? Other ideas?
> The MCL development team has decided that MCL's size is not the
> most important thing we have to work on right now, but it's
> still important to us.
you may have your reasons for _not_ being interested in the size
of applications generated by MCL,  however,  this is the primary
reason why I am not using MCL to develop any applications programs,
and I can't see myself doing so until that get's fixed.  Why?  well,
it looks stupid to deliver a simple program that takes up 1.4 megs.
especially when the same task can be done with a 20k application.
for example,  BinHex (the application) takes up something like 8k
on disk,  while the MCL BinHex application (which appears to do
the same thing,  although slower) occupies well over 1 meg of disk
space,  and it doesn't run well with less than two!

perhaps this is petty compared to the obvious advantages of using
MCL for development,  but I feel these things are important.  Generally,
I'd prefer to use MCL for everything,  including the tasks normally
done by the finder,  and for my own personal use it's great;  but,
I'd find it difficult trying to explain to a client why a program
with the functionality of TeachText more than 1meg of disk space, and
runs with 2 or more megs in ram...

    -john