In article <·················@netcom.com> ·······@netcom.com (William Paul Vrotney) writes:
>In article <···············@netcom.com> ······@netcom.com (David Pollen) writes:
>
>>
>> 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.
>
>They can not, usually.
This differs 180 degrees from my experience. I work on various parts
of an integrated suite of high-end graphics applications running on
SGI workstations that are written in a mixture of Common Lisp for the
mainline application-level code with C foreign functions implementing
the number crunching, I/O, etc. An "empty" lisp executable - one to
which we have not added a single line of our own code - starts out
anywhere from several times to an order of magnitude larger than our
competitors' finished products, depending on the particular
application. Once we have a fully functional system, we pay an
enourmous penalty in paging and other run-time performance due to the
size and complexity of the lisp environment, unless we take
extraordinary pains during development to mitigate these problems.
>
>>
>> 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?
>>
>
>A valid argument is that we are having a difficult time defining a Lisp
>specification that would make it easy for an implementation to have optimum
>tree shaking of a Lisp environment. But Lisp environments are getting better
>in this respect and your argument of the hardware factor is quite valid.
>Productivity should be more important than efficiency because the user of a
>computer program these days is more interested in results than worrying about
>whether his multimeg personal computer is using +/- a few megs. Garbage
>collection and dynamic typing are probably more important issues.
Again, this is just the opposite to my experience. Tree-shaking and
similar performance tuning not only is difficult to accomplish without
intoducing numerous bugs in real-world implementations, but this and
all other work-arounds typically advocated for overcoming the problems
associated with the size and complexity of most commercial lisp
implementations tend to work against the very advantages that using
lisp is thought to provide. For example, in order to really get the
most out of tree-shaking one must carefully avoid making calls to any
features of the environment that are to be thus eliminated. For
related issues, such as the problems associated with
garbage-collection based memory-management, it requires even more
effort to avoid them. This requires taking time and effort during
design and development (lisp makes one more productive?) and reduces
the potential feature set to end-users (lisp is more powerful?). The
argument that "RAM and disks are cheap, so it doesn't matter how much
of a hog your application is" is just false, in our market at least.
When a single frame of a film-resolution animated sequence can be 10's
of megabytes, the application which synthesizes or processes it _must_
be as small and efficient in its use of memory and other resources as
possible in order to be competitive. And this is in an industry where
100's of megabytes of RAM and 10's of gigabytes of persistant storage
is considered standard.
>
>Most people who make the "Lisp is just too big" line, from my experience,
>usually do not appreciate the above argument and are usually just trying to
>discourage programmers from writing programs in Lisp. Although they could
>support this statement in the past, that support seems to be going away with
>time. Time william tell.
>
>--
>Bill Vrotney - ·······@netcom.com
I do not try to discourage programmers from using lisp - I do
encourage them to be realistic about the trade-offs involved. As I
have stated in this newsgroup in the past, I feel that for some
applications no other language than a lisp-like one has the power and
features necessary to easily and efficiently accomplish the required
tasks. For other applications, however, the benefits of using lisp
are more than offset by its costs in resource utilization and other
run-time performance. Before choosing a language for a particular
task, you should be very clear about the cost/benefit tradeoff of
whatever programming tools you are considering using. Doing so has,
in my experence, sometimes shown that lisp is the best choice for a
given application and that sometimes it is not for another
application. There just is no such thing as "the best" programming
language - even though it is definitely true that some types of
languages are "the best for such-and-such a purpose." It turns out
that which type of programming language is "the best" will be
different depending on how you bind the metavariable "such-and-such".
------------------------------------------------------------
Kirk Rader ····@triple-i.com
In article <·········@triple-i.com> ····@triple-i.com (Kirk Rader) writes:
Again, this is just the opposite to my experience. Tree-shaking and
similar performance tuning not only is difficult to accomplish without
intoducing numerous bugs in real-world implementations, but this and
all other work-arounds typically advocated for overcoming the problems
associated with the size and complexity of most commercial lisp
implementations tend to work against the very advantages that using
lisp is thought to provide. For example, in order to really get the
most out of tree-shaking one must carefully avoid making calls to any
features of the environment that are to be thus eliminated. For
related issues, such as the problems associated with
garbage-collection based memory-management, it requires even more
effort to avoid them. This requires taking time and effort during
design and development (lisp makes one more productive?) and reduces
the potential feature set to end-users (lisp is more powerful?). The
argument that "RAM and disks are cheap, so it doesn't matter how much
of a hog your application is" is just false, in our market at least.
When a single frame of a film-resolution animated sequence can be 10's
of megabytes, the application which synthesizes or processes it _must_
be as small and efficient in its use of memory and other resources as
possible in order to be competitive. And this is in an industry where
100's of megabytes of RAM and 10's of gigabytes of persistant storage
is considered standard.
Other readers may benefit from some explanation provided by Mr. Rader
in email:
- Mr. Rader's application offers end-user programmability as a
competitive advantage. This very capability, though, limits the
usefulness of a treeshaker and hence prevents some image-size
reduction. (For example, one cannot delete program symbols if they
will be necessary later for incremental update of program
definitions.)
I agree that capabilities like end-user programmability and
incremental update carry some space cost. One must decide for a given
application and customer whether the net result is still a competitive
advantage or not. It may even be useful to offer both versions, with
and without such capabilities.
- Mr. Rader's application requires essentially real-time response.
Since no CL vendor currently offers real-time GC, the program must
therefore live with severe restrictions on dynamic memory
allocation--to the great detriment of programmer productivity.
I agree that use of CL in real-time applications is severely hampered
by the lack of commercially available real-time GC.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <·················@polaris.ih.att.com> ···@polaris.ih.att.com (Lawrence G. Mayka) writes:
[...]
>Other readers may benefit from some explanation provided by Mr. Rader
>in email:
>
>- Mr. Rader's application offers end-user programmability as a
>competitive advantage. This very capability, though, limits the
>usefulness of a treeshaker and hence prevents some image-size
>reduction. (For example, one cannot delete program symbols if they
>will be necessary later for incremental update of program
>definitions.)
>
>I agree that capabilities like end-user programmability and
>incremental update carry some space cost. One must decide for a given
>application and customer whether the net result is still a competitive
>advantage or not. It may even be useful to offer both versions, with
>and without such capabilities.
>
>- Mr. Rader's application requires essentially real-time response.
>Since no CL vendor currently offers real-time GC, the program must
>therefore live with severe restrictions on dynamic memory
>allocation--to the great detriment of programmer productivity.
>
>I agree that use of CL in real-time applications is severely hampered
>by the lack of commercially available real-time GC.
>--
> Lawrence G. Mayka
> AT&T Bell Laboratories
> ···@ieain.att.com
>
>Standard disclaimer.
I would (and did, in the mail to which Mr. Mayka refers) express the
problems in stronger terms. I used the "end-user programmability"
example as one particular instance of a more general point.
Tree-shaking, type declarations, foreign functions, and similar
optimizations are frequently cited as useful techniques for reducing
the size and improving the performance of lisp executables. They in
fact are useful only in so far as the particular application is not
making use of the features which are thus restricted or eliminated.
This means that by being able to take advantage of these
optimizations, the programmer has made a conscious decision to avoid
exactly the features of lisp which make it a more powerful and
expressive language than one like C or C++. If it is a trivial and
not onerous task to implement these optimizations for a given
application, then that should be considered evidence that it would
have been an equally trivial and not onerous task to have developed it
in a language like C or C++ instead of lisp. If they are required at
all, that should be considered evidence that it may have been _better_
to have developed it in a language like C or C++.
Mr. Mayka's response included the observation that most programs spend
80-90% of their time in 10-20% of their code, so it is really only
necessary to spend time optimizing that small fraction of the total
application. Without disputing whether this is or is not true for the
majority of application domains, it must be observed that the total
programming effort must include the effort of identifying the source
of program inefficiency as well as the effort of rewriting all those
parts of the program necessary so as to take advantage of whatever
optimizations are feasible and required. These rewrites are likely to
have ripple effects far outside of the small fraction of code that is
theoretically being optimized. An example of this is one technique
frequently used to avoid excess consing from so-called "boxed floats":
pass floating-point arguments in arrays instead of directly as
arguments to functions. If one takes the advice implied by the
"80/20" rule, that is to code the application quickly in the most
intuitive and natural way and worry about tweaking the slow parts at
the end, it may well turn out that the "tweaks" amount to a
substantial rewrite of the application as a whole. In the case of the
application which I cited as an example, a high-end paint and
animation system, one of the major criteria used by end-users in
judging the quality, or even correctness, of a program is that the
paint-brush on screen track the tablet stylus quickly, smoothly, and
continuously. This is not a "real-time" application in the
traditional embedded-systems use of the term, but it has similar
design requirements to such a system. My point in raising it is that
it is a simple and not-uncommon case where lisp's
garbage-collector-based automatic memory-management and similar
"productivity enhancing" features not only fail to confer any
particular benefit to this application, they actually hurt its
performance to an unacceptable degree. The level of effort it
requires to make sure that no part of the application conses too much,
and that the inner "real-time" loop conses not at all, is much greater
than would be inferred by placing faith in the validity or relevance
of the "80/20" rule.
As I will repeat yet again, I do not say any of this to imply that
lisp is useless or should never be chosen for any application. I do
state from personal experience that the claims of it making a
programmer significantly more productive compared to a language like C
or C++ are typically greatly exagerrated if not simply false when both
the quality of modern integrated C/C++ development and debugging
environments and the total costs of creating competitive
commercial-quality software in lisp are taken into account. In my
experience, the reason to use lisp is when an analysis of the problem
domain has shown that a good solution will both benefit from lisp's
more sophisticated features and will not suffer unacceptable
performance degradation due to the overhead associated with those
features. I feel that the range of applications which fail one or
both of these criteria is greater than is typically acknowledged by
lisp's evangelists. On those occasions when I have worked on projects
that met these criteria, however, I would have been extremely
frustrated to have been required to use anything but a lisp-like
language.
------------------------------------------------------------
Kirk Rader ····@triple-i.com