In article <···············@netcom.com> ······@netcom.com (David Pollen) writes:
Newsgroups: comp.lang.lisp
From: ······@netcom.com (David Pollen)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Tue, 19 Jul 1994 07:18:06 GMT
I don't understand why people consider Lisp too big to be highly usable.
This may have been true some time ago. But now with Hard Drive and
Ram prices falling like they have been and will be for years, how
can people support the "Lisp is just too big" line.
Alternatively, people might think Lisp has too many functions, but that
argument but I don't think that this argument cuts it either.
Are there any people out there who can tell me what the current and
valid arguments are for this theory?
I certainly don't believe Lisp is "too big," but here is my opinion of
why the RAM footprint of delivered Common Lisp applications remains a
significant issue and a challenge for CL vendors and developers:
- The massest of mass markets is in PCs, which typically have more
like 4-16 MB of RAM instead of the 16-64 MB typically available on
UNIX workstations.
- As fast as average RAM configuration grows, new operating-system
releases appear ready and eager to soak up the new RAM for themselves.
- The competitive necessity of ever-more-sophisticated GUI libraries
soak up additional RAM too.
- Embedded-control programs must often survive with a severely limited
quantity of RAM.
- UNIX users are used to a "tiny tools" approach, in which many
small-footprint processes run in separate address spaces,
communicating typically via a single primitive data structure (a file
of bytes). Indeed, some would say that the UNIX system was designed
to reward this approach (and, inevitably, to penalize any other). CL,
with its rich set of datatypes, gravitates more naturally toward
multiple threads running within a single address space. Reasonable
compromises, such as to have the "tiny tools" simply submit
expressions to a single CL server for evaluation or to put as much as
possible of CL into a shared library and shared memory, haven't come
into widespread use yet.
- CL users sometimes neglect to run any image-trimmer on their
application, effectively delivering part or all of an entire software
development environment as their application.
Needless to say, other programming languages present their own
challenges, which may be more serious and/or more inherent and hence
less amenable to remedy.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
From: Scott McLoughlin
Subject: Re: Why is Lisp too Big?
Date:
Message-ID: <PF9ZPc2w165w@sytex.com>
···@polaris.ih.att.com (Lawrence G. Mayka) writes:
> I certainly don't believe Lisp is "too big," but here is my opinion of
> why the RAM footprint of delivered Common Lisp applications remains a
> significant issue and a challenge for CL vendors and developers:
>
> - The massest of mass markets is in PCs, which typically have more
> like 4-16 MB of RAM instead of the 16-64 MB typically available on
> UNIX workstations.
>
Howdy,
I was just wondering: I know that there have been Lisp
implementations attempting to offer increased speed. Have there
been any Lisp offerings (compiled -- not interpreted) where the
goal was to minimize footprint of compiled executable images. I'd
be interested in hearing about any Lisp/Scheme compiler
implementations, not just CL.
=============================================
Scott McLoughlin
Conscious Computing
=============================================
In article <·················@polaris.ih.att.com>
···@polaris.ih.att.com "Lawrence G. Mayka" writes:
> I certainly don't believe Lisp is "too big," but here is my opinion of
> why the RAM footprint of delivered Common Lisp applications remains a
> significant issue and a challenge for CL vendors and developers:
I think you have to qualify a statement like "Lisp is too big." Which
dialect? Which implementation? I've read that there can be at least
a 4 to 1 difference in image size between two specific CL systems, and
few people seem to say if they're talking about a stand alone image of
the complete development enviroment when they complain about the size.
> - The massest of mass markets is in PCs, which typically have more
> like 4-16 MB of RAM instead of the 16-64 MB typically available on
> UNIX workstations.
I suspect you're right about this. How much pressure is there on vendors
to support small stand alone images? I bet it's nothing like the pressure
on devlopers for the mass market. I've seen reviews of C compilers where
the library overhead for a "Hello, World" program was measureed! How much
does that contribute to the image size of an app written in C? My own
experience suggests that for more than 10,000 lines the quality of the
compiler makes a bigger difference. I don't recall this _ever_ being
put into perspective for a C compiler, never mind a Lisp system, at
least in the reviews I've read in Byte, which is the only mainstream
magazine which I've read that used to review Lisp systems.
> - As fast as average RAM configuration grows, new operating-system
> releases appear ready and eager to soak up the new RAM for themselves.
I'm using a platform for which a C compiler uses more memory than the
system software, but I'm using a 16 bit MS Windows. The current 32 bit
version uses rather more RAM than the system itself. So I'm told.
The disk space consumed by VC++ is now about 10 times the size of Allegro
CL/PC! The important difference is that the overhead in the image of an
app could be as small a few K, or a few hundred K if you use Microsoft's
framwork classes, MFC - a bit like using Garnet with CL, only much less
demanding. If the MFC code were put into a shared library, it would be
about 300K. Can this also be done with Garnet? Why not?
> - The competitive necessity of ever-more-sophisticated GUI libraries
> soak up additional RAM too.
So put them in shared libraries. I've read that XLIB can add 1 MB to
a "Hello, World" program. An MS Windows users would laugh at that, and
ask why shared libraries aren't used. Perhaps they are, sometimes, but
there are people who always quote the worst stats, not the best. These
people are often reviews! No wonder X-Windows has a bad rep.
> - Embedded-control programs must often survive with a severely limited
> quantity of RAM.
True. This is why some people use Forth, C and even assembly.
> multiple threads running within a single address space. Reasonable
> compromises, such as to have the "tiny tools" simply submit
> expressions to a single CL server for evaluation or to put as much as
> possible of CL into a shared library and shared memory, haven't come
> into widespread use yet.
Doesn't this mean that all your utilities must then be written
with the one language and implementation? In reality, apps and
utils are written in a mixture. This is where Unix gets it right
in my opinion. This is what users _expect_. For the mass market,
they've been using DOS, so they've had no choice.
> - CL users sometimes neglect to run any image-trimmer on their
> application, effectively delivering part or all of an entire software
> development environment as their application.
I've seen posts in comp.lang.lisp from Lisp programmers who insist
on including the compiler _in_app_! Most app users (mass market
again) would run away screaming from anyone who suggests such a
practice. Just look at a typical embedded language, which as PAL,
VB (in Microsoft's Access database, their word processor, their
spreadsheet - hey, it's the same language. Users love that!),
xBase, and maybe even AutoLisp. They're nothing like CL, but
they are very popular, and some users even use them.
> Needless to say, other programming languages present their own
> challenges, which may be more serious and/or more inherent and hence
> less amenable to remedy.
Many apps I know use their own custom languages. A few of these
are hideous, such as Excel's macro language, but that's why VB
has replaced it in the current version. I'm hoping that Dylan will
atch on, as there seems to be little energy in the Lisp community
or anything but whinging about how "Lisp should be mainstream,
ut isn't", or "Why isn't Lisp more popular, like C?"
The answer could be simple: C vendors understand what mainstream
programmers want. Let's hope that Apple do, to, so that Dylan will
designed with mainstream programmers in mind. If they get it wrong,
it could take a long time to fix it. Esp since standards (like
ANSI CL) don't often fix a language, they just standardise what
vendors provide. So, who is to blame, vendors or their customers?
I dunno. I'm only commenting on what I've read in c.l.l.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
If "One likes to believe in the freedom of email", email
················@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!