I am a student who has been asked to prepare a report on limitations of
Lisp. However, I have never used Lisp before and cannot get reference
material on it here in Kenya. I would be grateful if someone could try and
explain to me about Lisp and its limitations as a programming language.

* Hasita Shah
| I am a student who has been asked to prepare a report on limitations of
| Lisp.  However, I have never used Lisp before and cannot get reference
| material on it here in Kenya.

I suggest you report the limitations of your teacher's pedagogical skills
to whoever has the authority to fire him and refund any expenditures you
may have accumulated.

there are many things that can fruitfully be requested of students with
little or no experience or knowledge to report on, in the hopes that
throwing a whole class into deep water will eventually let a few survivors
make it to land, but I am uncertain both of the nature of those who survive
under such conditions and of the usefulness of focusing on the limitations
of unknown languages.  even after many years of study, it takes bright and
conscientious students to be able to distinguish their own limitations from
those of the language under study.  limitations of a language usually
surface in practical use: when the amount of manual labor required to
obtain a needed behavior is growing out of proportions, one may be looking
at the limitation of a language, whether it be its specification or its
implementation, but even then most likely the implementation.

not that "the limitations of Lisp" wouldn't be an interesting report, but I
would much rather it be prepared by somebody with at least 20 years of
experience with the language and the specification, plus at least 5
different implementations, than an ignorant student under pressure.

you can still get access to reference material if you're on the Internet.
point your browser to <URL:http://www.harlequin.com/books/HyperSpec/>.
this is the specification for Common Lisp (or, as they point out, a derived
product of the specification as published by American National Standards
Institute (ANSI)).

#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".

I can't think of any serious limitations.   Occasionally, you'll find
an implementation of another language to be better for a particular
purpose, e.g. Java or TCL for graphical interfaces might be better
than what is offered by many vanilla Lisps.   There are some languages
which are better for specific purposes, e.g. SNOBOL beats everything
else at string processing.   I think array processing code looks
neater in C or Pascal than it does in Lisp, though that's a matter
largely of personal taste, and it would be perfectly possible to write
the appropriate read macros to rectify the situation -- I just can't
be bothered.

A common fallacy is that Lisp is slow.   That is a bit like saying
that German is loud.   Speed depends on the implementation, not on the
language.

Use www.altavista.digital.com and www.dejanews.com to find the good
stuff about Lisp from the net.

Limitations of Lisp:

1.  No more powerful than a Turing machine; able to compute only
    recursively enumerable functions.

3. Victim of substantial misinformation campaigns suggesting
   it has limitations that are probably imagined.

    I would say that the limitations of lisp are typically in various
implementations, and, while not intrinsic to the language, some are
very common.

1) The flexibility makes it hard to deliver compact executables.
2) Many systems do not have high-quality optimizers so code will
    sometimes be substantially slower than other languages.
3) Programming enviorments are typically several years behind
    those available in many other languages.

    On the strong side, lisp's extreme flexibility leads to short
software prototyping and development cycles.

So why are people (including, sometimes, myself) using Java, often
abandoning Lisp in the process?

(1) Lack of an agreed byte code means there's no portability of
object code, and no way of safely downloading and executing compiled
Lisp over the Internet.
(2) Lisp is not integrated with the Internet the way Java is.
(3) Lack of an agreed standard for graphics.

These are not intrinsic limitations.   They're the result of the
Lisp community not getting its act together.   They can be overcome.

In the case of (1), Lisp has a potential advantage over Java: its
primitives do complex things, and so the overheads of fetch and
interpret are often less than compiling in-line or subroutine calls.
The result is that byte-code interpreted Lisp is not significantly
slower than native-code compiled Lisp.   In the case of (2) and
(3), Lisp can catch up.

    Some 'applications' are actually a number of small executables.
For example, the product I'm working on now is ~25 executables.
if each one require static binding to ~1.5 MB, w're talking
~40 MB in statically-bound code.  It would be nice if some of this could

be alleviated with a lisp DLL or VM.

    If tools of a similar quality were available for Lisp, I could
seriously
justify using it on my job.

* David Hanley
| Some 'applications' are actually a number of small executables.  For
| example, the product I'm working on now is ~25 executables.  if each one
| require static binding to ~1.5 MB, w're talking ~40 MB in
| statically-bound code.  It would be nice if some of this could be
| alleviated with a lisp DLL or VM.

why static binding?  would you still need 25 executables in Lisp?

* (whoever)
| > > 3) Programming enviorments are typically several years behind
| > >     those available in many other languages.

that's because those other languages _require_ such environments to be
useful, while Lisp systems get by easily without.  it doesn't make sense to
do more than is necessary to solve a given problem, especially if what you
do extra has zero impact on your earnings and a major impact on your costs.
to make C++ usable at _all_, it _has_ to have those environments, so it
makes perfect business sense to build them, too.  note that C++ programmers
are approaching Lisp programmers in terms of productivity through the use
of these environments, but Lisp programmers are still way ahead.

also note that Lisp was years _ahead_ of other languages for a long, long
time, and that many of the ideas from the Lisp world have been adopted by
the other world.  also note that Lisp systems have remained largely
constant in size since about 1990, even falling in size, while Microsoft
products easily require 100 times more memory and 50 times more powerful
CPUs to do exactly the same ting (as far as user productivity is concerned)
as they did in 1990.  why are people still concerned with the size of Lisp
programs?

* David Hanley
| Well, it depends.  If it's going to be distributed, it helps.  It would
| be tough to write 'zip' in lisp with most common lisp systems, because of
| executable size.  However, some modern applications are large enough that
| an extra 1.5 MB might not matter.

if people insist on running every function from the command line, then it's
going to be a problem, but I never saw anybody complain about Word Macros
in Visual Basic on the grounds that you had to load all of Word 7 to run a
snippet of code.  or that to run an X application you had to fire up X
first.  or that to run a Unix command you had to boot a machine, log in and
run a shell.  all of these environments issues are taken for granted.  in
other words: it depends on what you consider your environment.  when most
users spend their entire working day in a single application, what good
does it really do to complain about the size of a standalone program when a
function call would have far smaller costs when run inside an application
the user is already running than a standalone program could ever hope for?

#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".

    1) A data simulation that requires a lot of tweaking: lisp wins.
    2) A gui with COM/WIN32/etc integration: C++ wins.
    3) A web applet: Java wins.

    This is particularly true for an obvious reason: people aren't going to
make
big lisp apps unless they can do some small ones first.  If people can't make
small apps in lisp, they're not going to progress to big ones.  Very simple.

    By the way, can you exaplin how user productivity is tied to CPU
power in your model?

    To place lisp in the same context makes no sense at all--it's a general
purpose language that ought to be good for writing all sorts of applications.
If I make a handy-dandy program that I want to distribute to a lot of users,
(say a file compresion program) no one will use it if they have to fire up
a lisp enviornment first to run it.

    What if the lisp OS is a virtual machine that runs under the OS,
like a Java VM?  The "exectuables" would be bytecode with a tiny
stub header that would feed them to the VM for execution.  So you can
click on an icon on the desktop and run a compact lisp executable.
There would only be one VM running at a given time.  If there's
two applications running, they will simply run as seperate threads in the same
VM space, for RAM savings.

    How about the problem of application paucity?  Well, what if the VM
is a java VM with extra lisp instructions?  There are quite a few useful
utils, apps and widgets in java already available.  There are VM's too,
which could simply be extended.  This would be a very effective
way to get a LISP os off the ground.

    It's an idea....

[...]

-------------
Subject:      Re: I got CW11.  Here's how I feel.
From:         da...@col.hp.com (David E Allen)
Date:         1997/01/20
Message-ID:   <5c0hs8$i54@nonews.col.hp.com>
Newsgroups:   comp.sys.mac.programmer.codewarrior

: I can only sympathize with programmers with slow 68k machines like yours.

And only a couple years ago the 68k machines were "fast". But software's one
and only job in life is to fill up ram and disk and choke all but the fastest,
newest cpu's. :-( I still find that perplexing, but I don't know of anyone
who is breaking that rule... How long before we will be sympathizing for those
with the "slow" powerpc machines? :-(

But thanks to Ron's suggestions, I bought the "Discovering Programming on
the Mac", which has CW8, and does a respectable job. I think I'll stick with
that rev and leave the glorious new stuff to those with tons of ram and disk
and cpu...

dave allen, colorado springs
--------------

[snip of remaining mild flamage, however accurate]

Clearly, small deliverables are something a general purpose programming
language should be able to accomplish, and common Lisp has problems with
this.

BTW, I like the idea of common Lisp compiled to Java byte codes. Are there
any developments along these lines in the works? Are Java's reflection
capabilities sufficient to the task of representing Lisp closures?

* David Hanley
| Static binding because none of the lisp windows compilers I'm aware of
| have a seperate .dll for lisp.  if they did, it would solve the problem
| right off.

I have talked to some people who profess to understand this DLL business,
and although they went on and on about how good and new this was (I think
the first time I used shared objects where high segments under TOPS-10 in
1980 or so), it never became clear to me exactly how much you pay for it.
one grudgingly admitted to a cost of about 5% overhead in a call-heavy
environment compared to static linking.  some of the *huge* Windows
applications appeared to run 20% _faster_ with static linking than with
DLLs in a test but this was not even commented on.  I guess DLLs are more
politically correct than performance.

| If it shortens your development cycle, it sure does have an effect on
| earnings.

I believe this is an unsubstantiated myth.  the evidence that it is true is
simply lacking.  "first-to-market" is _not_ the guarantee of success that
many (managers) believe it is.  (those winners who were "first to market"
were not really _first_, they were first to hit _big_.)  nothing suggests
that frequent releases is a guarantee of success, either.  still, many
(managers) believe this, too, like gospel.

| I agree that it is generally easier to program in lisp, and that it's
| betterfor many purposes, but I don't think you can really substantiate
| this claim either way.  You can always create a contrived enough test
| case to get the results you want.

if so, it would be very interesting indeed to look at the test cases.

various strongly substantiated reports indicate from 30% sustained average
(Richard P. Gabriel, on Lucid) to 10-fold peak advantage for Lisp/CLOS over
C++.

| > also note that Lisp was years _ahead_ of other languages for a long,
| > long time, and that many of the ideas from the Lisp world have been
| > adopted by the other world.
|
| And....???

I'm trying to point out to you that you criticize a snapshot of Lisp, while
you are obviously willing to judge other languages in terms of a process of
ongoing changes and improvements.  this may be because you think that Lisp
is a "finished" language in the sense that you don't expect further changes
or development.  again, this is _your_view_of_Lisp_, and has very little to
do with Lisp itself.  that you also limit what Lisp is so that it _cannot_
be whatever would have been a winner indicates that you either ignore or
don't know the past.

| You are stubbornly ignoring the issue.

geez, first DLLs and now this.  are you a member of the Martin Rodgers fan
club, too?

| This is particularly true for an obvious reason: people aren't going to
| make big lisp apps unless they can do some small ones first.

oh, I see, so this is "obvious", which means you won't even _attempt_ to
elaborate and you will accuse people of "stubbornly ignoring foo", for
suitable values of "foo" if they reject your "obvious" claim.  great!

FYI, this is _your_ view of Lisp and of applications.  you may find people
who agree with you, but the important thing with beliefs is to challenge
them and find contrary views.  your response to that is, of course, that
I'm "stubbornly ignoring the issue", as if we had a government approved
agenda and I was somehow in violation of it by bringing up ideas and angles
that you are dead set against considering.

| If people can't make small apps in lisp, they're not going to progress to
| big ones.  Very simple.

it's actually amusing, in a sad and tragic sense, that you have already
decided on this and is impervious to empirical evidence to the contrary.

| By the way, can you exaplin how user productivity is tied to CPU power in
| your model?

FWIW, they are clearly unrelated.  users are no more productive with 50
times faster CPU's with 100 times more memory if they use the latest and
greatest software from Microsoft.  an acute observation from at least 20
years ago was that every program grew to consume all available resources.
this observation has been strongly reinforced on the Windows platform.

as for productivity in real money terms: according to a report in the
Economist earlier this year, the cost of producing any piece of business
communication dropped along with advances in computers from 1950 through
1980.  from 1985 through 1995, it rose sharply enough to consume all
earnings made since 1950.  it is significantly more expensive to produce a
business letter in 1997 than it was in 1950.  despite many technological
advances with a very high price tag, a secretary does not produce any more
measurable output now than in 1950 -- in fact, the evidence suggests that
obtaining _half_ the productivity of a 1950's secretary in 1997 is a major
feat.  the fact that managers write their own reports at down to 1/10th of
the speed of a secretary that used to be paid 1/10th of their salary also
means that the time spent producing a letter or a report can cost as much
as 100 times more than it did in 1950, when managers scribbled unreadable
notes and very quick and efficient typists corrected their spelling,
grammer, and language and adhered to "company style" effortlessly.

there are other areas where computers have introduced major advances, such
as communication, but this didn't happen until wide area networks began to
be deployed in the mid-90's, and this was clearly _not_ due to massive
increases in CPU and memory on the disconnected PC's, who _still_ are not
very good at interchanging information.  (they're _very_ good at being the
same kind of propaganda and marketing reception equipment as TV's, though.)

| To place lisp in the same context makes no sense at all--it's a general
| purpose language that ought to be good for writing all sorts of
| applications.  If I make a handy-dandy program that I want to distribute
| to a lot of users, (say a file compresion program) no one will use it if
| they have to fire up a lisp enviornment first to run it.

"you are stubbornly ignoring the issue."

it's _your_view_ of Lisp that is at fault here, not Lisp.  people _were_
willing to run Windows as a separate environment apart from their usual DOS
commands to run "Windows software".  people are willing to fire up various
programming environments (except they aren't called that) to run useful
programs _inside_ them already, many of them in your neighborhood (i.e.,
Windows), such as Excel or Word.

| > in other words: it depends on what you consider your environment.  when
| > most users spend their entire working day in a single application,
|
| I've not notice this.

that suggests to me that you may have neglected to notice other aspects of
the users of which you speak so generally in such specific terms, as well.

| > what good does it really do to complain about the size of a standalone
| > program when a function call would have far smaller costs when run
| > inside an application the user is already running than a standalone
| > program could ever hope for?
|
| What you seem to be suggesting here is that the user works in alisp shell.

uh, now I wonder if you have noticed much around you at all.  how do people
interact with their (Windows) environment today if it is _not_ that they
work in what is effectively a C++ shell?  would they have to type in C++
code for you to consider it a C++ environment?  they fire up "apps" (what a
godawful abbreviation) _inside_ that environment, and some of them may have
to start up the whole environment first (remember the DOS command grossly
misnamed "win"?).  Unix users work in a shell that works hard to make it
immaterial if a "command" is a builtin or a "function" residing on disk as
a separate program.  whether a program is a part of the "shell" or is fired
up in a separate (operating system) process should not matter to the user.

indeed, that it matters to _you_ is symptomatic of a strained relationship
with environments, programming or otherwise.  other Windows users seem to
be equally tied up in their _particular_ environment, completely forgetting
any semblance of conceptualization of "environment" or its purpose for a
computer user.  I wonder why this is.  I wonder if this is a contributing
cause to my strongly disliking the Microsoft "environments", too.

| That's unrealistic in the basic sense, but a lisp OS will solve the
| issue.  How can users be induced to run a lisp OS?

this, again, suggests that you have a _very_ narrow view of Lisp.  it is
apparent that you don't even think of Lisp as an environment, much less an
environment-building language.  I do.  to you, Lisp is a language, and any
application is built "with Lisp, on top of my existing environment", which
is Windows, right?  in a sense, Windows is a result of the way C++ builds
environments, like Unix is a result of how C does it.  if you had looked at
the Lisp machines, you would have seen what kind of an environment Lisp can
build.  likewise, the Emacs programming and text processing environment
(I'll bet you classify Emacs as an "editor") is a result of what it is easy
and convenient to do in Emacs Lisp.

also, users aren't induced to run operating systems or even applications --
they are induced to do whatever is necessary to continue to get paid.  many
programmers complain that even _they_ cannot choose their own tools, for
fear of losing their jobs.  (this appears, for some _odd_ reason, to apply
mostly to Windows programmers.)

#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".

In article <3468D017.A4B40...@netright.com.delete.me.silly>, David Hanley <da...@netright.com.delete.me.silly> writes:

A LispOS takes this a step farther, and says why do you even NEED
an OS, when all the useful applications are written
as small Lisp "applets"?

This is great, except for the true state of the world doesn't match.
Where are all the lisp "applets" and needed utilities?
And where is a Lisp environment that can be actually BE SHARED
by multiple lisp applications?  I think both are missing.

David Hanley wheezed these wise words:

No doubt a CL to C compiler could be ported to Win32 and modified to
support placing the runtime in a DLL. As noted above, this has been
done with Gambit C, so why not CLiCC or Eclipse? There's probably
nothing to stop this from being done - it just hasn't been done yet.

I'd be happy to pay for such a compiler, if it included support for as
many Win32 features as, say, LWW. Meanwhile, when I want a CL for
Win32, I'll use LWW and live with static linking, or use Gambit C for
all those "tiny" apps that make static linking look expensive.

I've seen two styles of interface builders. One is the kind that edits
relationships between interface elements, and the other edits the
positions of elements within a "form". The former is used by ACL/PC
and LWW, while the latter is used by VC++, VB, etc. When you're
interested in very fine details of the user interface, the latter can
give you more control. A layout manager lets the machine handle more
of these details, which is great for the programmer, but not so great
for the user who knows _exactly_ what the user interface should look
like, sometimes down to the pixel level.

Both interface builder styles are valid, IMHO, as they satisfy
different needs. The "executables-on-a-button-click" point is another
such issue. Not all programmers need to create an executable often
enough to justify this. If a Lisp environment lacks such a button,
then maybe that tells us about the needs of most Lisp programmers.
Similarly, the presence of such a button in an IDE for C++, VB, Java,
or whatever, tells us about the needs of other groups of programmers.
Again, I think that these needs are equally valid. I just don't expect
to see many C++ environments with a listener window!

Maybe they're confusing Lisp with Cobol...? _We_ know there's a
difference, but does a Lisp newbie? I wonder. Stigma is a problem.

IMHO C++ has stagnation and inbreeding, but do these things hurt C++?
I think they will, and there are compiler writers who certainly say
so. Not that everyone listens, mind you.

The old argment in favour of C is the "Hello, World" app. I don't
think this is a weak argument because that's not a useful app, but
because it doesn't scale well. It does, however, make it appear easy
to learn C. It's only later that you discover how hairy the language
is! By then you've already learned C, so the damage is done. You'll
believe that you can write code in it. Worse, you _can_ write code in
it! Hairy code, but it's still code.

Perhaps with Lisp you have to be more patient, until you reach a point
where it all clicks and makes sense. This is why I'm not suprised that
so few programmers discover Lisp, never mind the virtues of using
Lisp. Too many programmers just don't have the time to _learn_.
Instead, they can find loads of people telling them how wonderful
C/C++ is, so it must be true. How can those weird Lisp people be
right, when all they do is talk about "reflection", "functional
closures", and other jargon? IME, the programmers most negative about
Lisp are those who don't know what these terms mean, never mind how
useful such features might be. So we also have a jargon stigma.

How about you and me write a book called, "Common Lisp for C++
Programmers"? We could teach Lisp using exactly the kind of code that
can be found in many C++ tutorials, thus avoiding the AI stigma, with
loads of emphesis on solutions to "real world" problems, like database
and networking apps. The final code example could be a simple web
server with CGI support, mapping queries to function calls, plus
dynamically pouring results from database queries into HTML pages.
There are enough commercial web server tools that do this to class
such a server as pretty damn "real world"!

Object Oriented Programming in Common Lisp
A Programmer's Guide to CLOS
Sonya E. Keene
Addison-Wesley 1988
ISBN 0-201-17589-4

If you are just looking for some chapters where you can see what
programming with CLOS looks like you might want to read Chapter 14 in
Winston & Horn's Lisp (3rd edition) and chapters 21 to 24 for examples
of applications, or Chapter 11 in Paul Graham's ANSI Common Lisp.
For a rapid overview that includes some comparisons with C++ see
Appendix A of

The Art of the Metaobject Protocol
Gregor Kiczales, Jim des Rivi`eres and Daniel G. Bobrow
The MIT Press, 1991
ISBN 0-262-11158-6 (hardcover)
ISBN 0-262-61074-4 (paperback)

One teacher who worked with linguists who had not even used a computer
before their course (this was quite a few years before the PC era),
reported that he was deeply impressed how soon these people were able
to write Lisp programs for their professional work, using Lisp to solve
their actual problems - not some toy stuff like what's common in courses.

Good teachers and good tutorials are certainly welcome, but the mental
approach to learning and programming is much more relevant than all the
technical problems together, as far as I can tell.

Too many people in this profession are simply coders, usually not very
interested in the first place to think much beyond the horizon of turning
a pretty much worked out solution into executable code in one and only one
programming language, of which they've seen some examples.

Frankly, I'm not sure why I should want such people to touch Lisp - all
its flexibility won't help a closed mind. Don't misunderstand that - I'm
all for providing as much and as high quality an education to people being
interested in learning - i.e. enjoying to go beyond what they know, even
partially invalidating what they once "knew" - and removing barriers that
people can really invest energy and time in such things, not only for a
job, but in many different areas of life. However, the latter are really
philosophical/social/political problems (aka "economy has quite destructive
effects for humanity"), and the human condition won't be helped very much
by introducing just another few people to Lisp programming.

If you want more dull coders programming horrible applications in Lisp,
something like "Web Applications in Common Lisp" might help. If you want
more people to act intelligently and use the available tools skillfully,
I fear you're looking in the wrong corner for a solution. Bad programmers
using Lisp do still write bad programs - probably even more so than with
tools where the amount of damage they can do is limited by (in your or my
view perhaps irritating) technical constraints.

Nov 11, 1997 20:08, Raf Cavallaro <raff...@pop.tiac.net> wrote:

 >BTW, I like the idea of common Lisp compiled to Java byte codes. Are
there
 >any developments along these lines in the works? Are Java's reflection
 >capabilities sufficient to the task of representing Lisp closures?

Kawa is a free Scheme interpreter in Java that compiles Scheme to J-code.
 <http://www.copsol.com/sgmlimpl/tools/kawa/faq.html>

A few R4RS items are missing. Kawa supposedly allows access to Java's
classes and methods. I haven't tried it myself as I can't figure out how to
set the Kaffe classpath under MkLinux. Should try under MacOS someday, but
that would require getting the JDK to run with MRJ 1.5

(eqv? InternetC++ Java)
=> #t
(member? 'Java cryptic-language)
=> #t
(cool? (and Scheme Dylan))
=> #t

Robert D. Skeels   ath...@earthlink.net | "created and sent via the
Los Angeles, CA   illustration & design |      Cyberdog mail system"
   http://home.earthlink.net/~athene    | eti kai nun Hellada phileo

In article <MPG.ed3ce8c34f83048989...@news.demon.co.uk>,
 Martin Rodgers
<mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk>
wrote:

Don't count the Lisp-environment. That's just my notion of a shell.
Actually MCL is much smaller than the Win95 Explorer and does take only
slightly more memory than the MacOS Finder.

Or do _you_ count in the size of the Visual C++ MFC*.DLL and the
associated C++ runtime libraries for Win95? They take up much more
memory than MCL on a Mac.

Nah, the size-argument is mostly ridiculous in the modern OS market. The
sizes - and memory usage - of MCl or ACL (don't know about LWW) don't
count in times of many-megabyte-memory systems like Windows95 or
possibly NT.