In article <···············@netcom.com>,
David Pollen <······@netcom.com> wrote:
>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.
>
I believe the "too many functions" concept is close to the mark. Dykstra
once criticicised PL/I by saying its size and complexity precluded complete
mastery. A similar criticism applies to Lisp. In other words, there is so
much to learn in Lisp that you must study it much longer than with other
languages before you get a feeling of "Now I thoroughly understand," if in
fact you ever do. This is equally true of C if one counts learning the
standard library as part of learning the language, but people rarely do.
John Doner ·····@math.ucsb.edu or ·····@aero.org
From: Scott McLoughlin
Subject: Re: Why is Lisp too Big?
Date:
Message-ID: <DsVsPc2w165w@sytex.com>
> mastery. A similar criticism applies to Lisp. In other words, there is so
> much to learn in Lisp that you must study it much longer than with other
> languages before you get a feeling of "Now I thoroughly understand," if in
> fact you ever do. This is equally true of C if one counts learning the
> standard library as part of learning the language, but people rarely do.
>
> John Doner ·····@math.ucsb.edu or ·····@aero.org
Howdy,
Guess I'm a young fellow, but I am seriously wondering --
WHY, oh WHY wasn't CL developed as a "core language" plus "standard
library" type of standard. This would allow, among other things,
an implementation of the "standard library" in the core language that
would be portable. Vendors could then optionally "inline" and
optimize portions of the standard library like many C vendors do.
Furthermore, while SERIES and LOOP are nifty, what are they
doing in the language standard? I would think that these would be
relegated to OPTIONAL libraries, implemented, of course, in the
standard core language + standard libraries.
I don't think that standardizing _everything_ is a good
idea for a language. There's still lots of room for industry
standards and de facto standards.
Defining a small language+libraries would encourage
vendors to come up to speed quickly on the language standard, and
then portable libraries, both free and commercial, could flourish
with fewer (no?) portability concerns.
One way to think about it is -- a flourishing language has
third party tool and library vendors advertising commercial add ons
in Dr. Dobb's Journal. I don't see why this isn't possible for Lisp.
I love Lisp. Everyone I turn onto Lisp thinks it's cool, especially
(unwind-protect) (throw) lexical (return-from) and (defmacro). Cool
sells (look at Visual Basic). But there's got to be third party
support and advertisements to show the boss and at least a
half-way decent version available for under ~$150.00 (like
Turbo C++ for windows).
Anyway, what is the rational for the mega-standard
approach? Are any sane, commercially oriented folks trying
to put together an alternative standard? (I've heard of
Eulisp, but know nothing of it.)
=============================================
Scott McLoughlin
Conscious Computing
=============================================
In article <············@sytex.com> ····@sytex.com "Scott McLoughlin" writes:
> Furthermore, while SERIES and LOOP are nifty, what are they
> doing in the language standard? I would think that these would be
> relegated to OPTIONAL libraries, implemented, of course, in the
> standard core language + standard libraries.
Have you taken a look at Dylan (see the Lisp FAQ if you haven't)?
That's how I'd like a modern Lisp to be, only with a Lisp syntax,
which is what "Classic" Dylan had, before it was replaced with
the current "Algol"-like syntax.
Apple are designing a core language, with things like I/O etc left
as optional library components.
> One way to think about it is -- a flourishing language has
> third party tool and library vendors advertising commercial add ons
> in Dr. Dobb's Journal. I don't see why this isn't possible for Lisp.
This is what Apple are hoping will happen with Dylan. I don't expect
to happen with Lisp anymore than for Smalltalk, tho I'm not saying
it can't happen or that even that it isn't happening. It's just not
enough for some of us. Maybe it's a marketing problem, but it could
also have something to do with the language (specific dialects and
implementations of Lisp) for all I know.
> Anyway, what is the rational for the mega-standard
> approach? Are any sane, commercially oriented folks trying
> to put together an alternative standard? (I've heard of
> Eulisp, but know nothing of it.)
I also know little of Eulisp. I'd love to see a comparison made
between it and Dylan. I have the Dylan manual, and I've been
reading comp.lang.dylan for a number of months, and if I had to
use a language other than Lisp, which is very likely, then I
hope it can be Dylan. I can't say anything about Eulisp, as I
know too little about it.
--
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!
The memory and disk are cheap argument doesn't cut it (at least this
year). Franz's allegro cl with common windows starts with an image
(according to top) of 16 meg. Add in my application and it starts at
over 20 meg. On a Sparc 10 with 96 meg of memory, 500 meg of swap, I
have an application that runs several processes as well as the lisp
application. Running this way hits the machine so badly that my
colleague's c++ compiles take several times longer than usual.
I rewrote the application in c++ using essentially the same
algorithm. The only difference is that I no longer need a thread to
hook up to the other processes in the system. The image starts at 2
meg, rarely grows to more than 10. The machine is much more usable by
two people. And my application is at least an order of magnitude
faster, in CPU time, let alone real time. (the lisp version took
minutes to expand 100's of nodes in the search space, the c++ uses
10's of seconds to expand 1000's of nodes; both programs interpret the
same rule language in the same way.)
Also, while I optimized the compilation of critical parts of the
algorithm in lisp (after profiling), I compile the c++ with -g and no
optimization.
I've worked in lisp for 15 years, but I think that when I start my
next project I'll give serious consideration to starting in c++ rather
than lisp.
|Bryan M. Kramer, Ph.D. 416-978-7569, fax 416-978-1455|
|Department of Computer Science, University of Toronto |
|6 King's College Road, Room 265A |
|Toronto, Ontario, Canada M5S 1A4 |
From: William Paul Vrotney
Subject: Re: (lisp vs c++ performance) was Why is Lisp too Big?
Date:
Message-ID: <vrotneyCtIrxw.Mtp@netcom.com>
In article <······················@wotan.ai.toronto.edu> ······@cs.toronto.edu ("Bryan M. Kramer") writes:
> The memory and disk are cheap argument doesn't cut it (at least this
> year). Franz's allegro cl with common windows starts with an image
> ...
> two people. And my application is at least an order of magnitude
> faster, in CPU time, let alone real time. (the lisp version took
> minutes to expand 100's of nodes in the search space, the c++ uses
> 10's of seconds to expand 1000's of nodes; both programs interpret the
> same rule language in the same way.)
Who are you trying to dupe? Any of us can do (dissassemble 'foo) and "cc -S
foo.cc" where foo is a node expansion bottleneck and study the real
difference between Lisp and C++ efficiency on current implementations.
Two Lisp interpreters "interpret the same language in the same way". But
there is a vast difference between the speed of two Lisp interpreters
depending on the implementation and environment.
> I've worked in lisp for 15 years, but I think that when I start my
> next project I'll give serious consideration to starting in c++ rather
> than lisp.
You are making yourself sound like the very person the originator of this
thread was complaining about.
> |Bryan M. Kramer, Ph.D. 416-978-7569, fax 416-978-1455|
^
|
Not impressed ---|
--
Bill Vrotney - ·······@netcom.com