From: ···@paradigm.com
Subject: why lisp is dead
Date:
Message-ID: <485@paradigm.com>
Here I am, a lisp hacker, who learned what a macro was from JONL,
and what lisp microcode was from RG, and what lexical scoping was
from GLS.
So when I go to write an expert system at a startup-company
do I decide to use LISP?
NO!
Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
three costs:
(1) technical cost of the overly-complex and large runtime portions.
(2) financial cost-of-sales for runtime licenses.
(3) administrative costs of runtime licensing procedures.
Do language vendors for C,FORTRAN,PASCAL generally charge a runtime
license fee? No, they do not. (Not even 3rd-party vendors).
But lisp vendors generally have various "technical" rationalizations for
per-instance runtime licensing costs and complexities. No need to go
into these here. The result is a classic downward spiral:
Fewer Commercial/Developers Users of Lisp
=> Justification for obtaining revenue from runtime licenses
=> Fewer Commercial/Developers who will want to use Lisp
=> need for higher runtime license costs for more revenue
=> Fewer users of lisp ...
-gjc
In article <···@paradigm.com> ···@paradigm.com writes:
...
>So when I go to write an expert system at a startup-company
>do I decide to use LISP?
>
>NO!
>
>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
>
>three costs:
>(1) technical cost of the overly-complex and large runtime portions.
>(2) financial cost-of-sales for runtime licenses.
>(3) administrative costs of runtime licensing procedures.
>
>Do language vendors for C,FORTRAN,PASCAL generally charge a runtime
>license fee? No, they do not. (Not even 3rd-party vendors).
>
>But lisp vendors generally have various "technical" rationalizations for
>per-instance runtime licensing costs and complexities. No need to go
>into these here. The result is a classic downward spiral:
...
>-gjc
Perhaps you should try Scheme. Aside from the academic/no-cost
compilers with source, Chez Scheme [Cadence Research Systems: (812)
333-9269] has an application builder which links in a minimal runtime
for stand-alone applications. Chez runs on Sun3/4, Vax, Apollo, 88K
and various other boxes.
Using Scheme gets rid of 1,2,&3. Don't forget the cost of storage
leaks. [I know of at least 1 C++ product which uses 5 heaps!].
Also, don't forget the cost of development time. If you use a
productive enviroment which gets your software done in 1/2 the time of
batch-compiled languages (C,FORTRAN,PASCAL) you may just hit your
market windows.
Perhaps I should ask what you mean by Lisp. Lisp 1.5 probably is
dead!
-Ken Dickey
In article <····@tekcrl.LABS.TEK.COM> ····@tekchips.LABS.TEK.COM (Ken Dickey) writes:
In article <···@paradigm.com> ···@paradigm.com writes:
...
>So when I go to write an expert system at a startup-company
>do I decide to use LISP?
>
>NO!
Perhaps you should try Scheme. Aside from the academic/no-cost
compilers with source, Chez Scheme [Cadence Research Systems: (812)
333-9269] has an application builder which links in a minimal runtime
for stand-alone applications. Chez runs on Sun3/4, Vax, Apollo, 88K
and various other boxes.
Ken also probably should have mentioned MacScheme (Lightship Scheme?)
which can produce ~120K applications for distribution. I believe
there is no licensing fee.
Also, MACommonLisp (disclaimer alert!) has a single shot licensing
fee. That is, a developer pays $100 a year, for any number of copies
of any number of applications.
-andrew
From: lawrence.g.mayka
Subject: Re: why lisp is dead
Date:
Message-ID: <14980@cbnewsc.ATT.COM>
In article <···@paradigm.com> ···@paradigm.com writes:
>So when I go to write an expert system at a startup-company
>do I decide to use LISP?
>
>NO!
>
>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
>
>three costs:
>(1) technical cost of the overly-complex and large runtime portions.
>(2) financial cost-of-sales for runtime licenses.
>(3) administrative costs of runtime licensing procedures.
Until the world is ready for Lisp machines...
You could develop in (portable) Common Lisp in your favorite
environment but deliver your application in Austin Kyoto Common
Lisp. My impression is that, with the proper arrangements, the
esteemed professors in Kyoto do not impose (2) and (3). Even (1)
is not so much of a problem with AKCL as with some other Common
Lisp implementations.
Can you name your hardware platform? For example, if you're
developing for an IBM-compatible PC with 640 Kbytes of RAM, your
situation is probably beyond hope unless you can make do with
Xlisp.
Lawrence G. Mayka
AT&T Bell Laboratories
···@ihlpf.att.com
Standard disclaimer.
From: Charles Noren
Subject: Re: why lisp is dead
Date:
Message-ID: <1581@dinl.mmc.UUCP>
In article <·····@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
>In article <···@paradigm.com> ···@paradigm.com writes:
>>So when I go to write an expert system at a startup-company
>>do I decide to use LISP?
>>
>>NO!
>>
>>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
>>
>>three costs:
>>(1) technical cost of the overly-complex and large runtime portions.
>>(2) financial cost-of-sales for runtime licenses.
>>(3) administrative costs of runtime licensing procedures.
>Can you name your hardware platform? For example, if you're
>developing for an IBM-compatible PC with 640 Kbytes of RAM, your
>situation is probably beyond hope unless you can make do with
>Xlisp.
Doesn't the copyright statement of Xlisp prohibit the comercial use of Xlisp
embeded in an application?
--
Chuck Noren
NET: ncar!dinl!noren
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
Denver, CO 80201-1260
Phone: (303) 971-7930
In article <····@dinl.mmc.UUCP> ·····@dinl.UUCP (Charles Noren) writes:
>Doesn't the copyright statement of Xlisp prohibit the comercial use of Xlisp
>embeded in an application?
No longer -- Xlisp 2.1 is fully public domain (its part of the
winterp package and the university with winterp does not allow such
restrictions on ftp'able software, as I recall).
Ron
In article <····@quiche.cs.mcgill.ca> ·······@quiche.cs.mcgill.ca (Ronald BODKIN) writes:
>In article <····@dinl.mmc.UUCP> ·····@dinl.UUCP (Charles Noren) writes:
>>Doesn't the copyright statement of Xlisp prohibit the comercial use of Xlisp
>>embeded in an application?
> No longer -- Xlisp 2.1 is fully public domain (its part of the
>winterp package and the university with winterp does not allow such
>restrictions on ftp'able software, as I recall).
> Ron
Actually, only the version of Xlisp 2.1 embedded in the WINTERP
distribution falls under MIT's nonrestrictive copyrights -- I asked XLISP's
author, David Betz, whether the copyright for the WINTERP version of XLISP
could be changed in order to abide by the MIT X Consortium's requirements.
Betz graciously agreed.
Since this message will undoubtedly generate a few e-mail questions on
where to get WINTERP and such, please note that I will be out of town till
May 6th. As a hint:
anonymous ftp from expo.lcs.mit.edu, directory contrib/winterp
file winterp.tar.Z
-------------------------------------------------------------------------------
Niels Mayer -- hplabs!mayer -- ·····@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
In article <···@paradigm.com> ···@paradigm.com writes:
>>So when I go to write an expert system at a startup-company
>>do I decide to use LISP?
>>
>>NO!
>>
>>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
>>
>>three costs:
>>(1) technical cost of the overly-complex and large runtime portions.
>>(2) financial cost-of-sales for runtime licenses.
>>(3) administrative costs of runtime licensing procedures.
>···@cbnewsc.ATT.COM (lawrence.g.mayka) replies
> Until the world is ready for Lisp machines...
Common Lisp is more of an Operating System than just a programming
language. You certainly don't pay Lisp license fees for
applications delivered for a Symbolics or an Explorer.
You assume that the delivery machine already has UNIX, or MS-DOS, or
whatever. If you have to deliver your application with an Operating
System, you would certainly have to pay a license fee for the OS.
You are buying into the OS, not C, when you use C as your programming
language.
Common Lisp is quite healthy. In my opinion, the growth of UNIX, C and C++
is cancerous.
Common Lisp will be an Operating System. When you start
writing programs that use multiprocessors and parallelism,
you will rapidly discover that UNIX and C are dead.
-Kelly Murray (Top Level, Inc.)
······@cs.umass.edu
From: ···@paradigm.com
Subject: Re: why lisp is dead
Date:
Message-ID: <509@paradigm.com>
In article <·····@dime.cs.umass.edu>, ·····@Vega writes:
>
> Common Lisp is more of an Operating System than just a programming
> language.
False. A CL does *not* have to implement:
- FILESYSTEM - EDITORS
- NETWORKING - DEVICE DRIVERS for DISK/TAPE/NETWORK ...
- SCHEDULING - WINDOW SYSTEM
- PROTECTION - INTERLOCKING - INTERPROCESS COMMUNICATION
There is a heck of a lot in an O/S such as VMS or UNIX.
For that matter, there is a heck of a lot in something like
the Symbolics release 6.x O/S, or the LMI-LAMBDA release 3.x
Most all of the stuff of conventional O/S.
So why is it that some CL implementations under say Unix, are
now bigger than an entire lispmachine O/S image???
> You certainly don't pay Lisp license fees for
> applications delivered for a Symbolics or an Explorer.
False. You pay one HELL of a lot, since you need to buy a hardware board
and pay for additional software licenses when you want to support
a Lisp application on your MAC or SUN in that manner. The user must
also pay additional monthly hardware support fees.
> Common Lisp is quite healthy. In my opinion, the growth of UNIX, C and C++
> is cancerous.
C is FORTRAN-DONE-RIGHT, so who could argue with that?
And C++ perhaps is just filling the space that could have been taken up
by reasonable lisp implementations.
-gjc
From: lawrence.g.mayka
Subject: Re: why lisp is dead
Date:
Message-ID: <15057@cbnewsc.ATT.COM>
In article <···@paradigm.com> ···@paradigm.com writes:
>In article <·····@dime.cs.umass.edu>, ·····@Vega writes:
>> Common Lisp is more of an Operating System than just a programming
>> language.
>False. A CL does *not* have to implement:
> - FILESYSTEM - EDITORS
> - NETWORKING - DEVICE DRIVERS for DISK/TAPE/NETWORK ...
> - SCHEDULING - WINDOW SYSTEM
> - PROTECTION - INTERLOCKING - INTERPROCESS COMMUNICATION
Perhaps it is more accurate to say that Common Lisp attempts to
provide a portable interface to a software development
environment. Common Lisp includes BREAK, INSPECT, TRACE, STEP,
COMPILE, LOAD, EVAL, ED, PPRINT, and a host of other
environment-related forms.
>So why is it that some CL implementations under say Unix, are
>now bigger than an entire lispmachine O/S image???
Large Common Lisp images typically include a more or less complete
software development environment, plus a number of
operating-system-like capabilities such as preemptive
multiple-process scheduling.
>> You certainly don't pay Lisp license fees for
>> applications delivered for a Symbolics or an Explorer.
>False. You pay one HELL of a lot, since you need to buy a hardware board
>and pay for additional software licenses when you want to support
>a Lisp application on your MAC or SUN in that manner. The user must
>also pay additional monthly hardware support fees.
The point is that any calculation of "overhead" depends on the
assumptions one is willing to make about typical customers. If
targeted customers usually already have a Lisp machine and a
Lisp-based operating system, these are no longer "chargeable" to
the application. Even on a computer running the UNIX System, if
customers typically already have a Common Lisp implementation and
the application is packaged on that assumption (e.g., as a
loadable binary), the Lisp is no longer "application overhead."
Lawrence G. Mayka
AT&T Bell Laboratories
···@ihlpf.att.com
Standard disclaimer.
From: Jeff Dalton
Subject: Re: why lisp is dead
Date:
Message-ID: <2222@skye.ed.ac.uk>
In article <·····@dime.cs.umass.edu> ·····@Vega writes:
>In article <···@paradigm.com> ···@paradigm.com writes:
>>>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
>>>
>>>three costs:
>>>(1) technical cost of the overly-complex and large runtime portions.
Isn't it a financial cost too? One has to buy larger and more
powerful machines in order to run Lisp; and such machines cost more.
For example, I use a ~10 mips, 8 megabyte machine. It runs a wide
range of programs written in C without much trouble, but if I want to
use a Common Lisp on it, I usually stick to KCL because larger ones
take a noticable performance hit from paging.
Moreover, I find it really annoying that I can't write little programs
in Lisp (because they automaticaly become big programs) and have to
use C instead. Common Lisp implementations are a step backwards in
this respect compared to earlier Lisps such as Franz. [Note that I
say implementations. Someone could, I suspect, produce a Common Lisp
with different properties.]
Not only that, in some ways C has a better programming environment
than the Lisps that would run on the same machines. (Try dbxtool
on Suns, for example).
>>>(2) financial cost-of-sales for runtime licenses.
>>>(3) administrative costs of runtime licensing procedures.
>Common Lisp is more of an Operating System than just a programming
>language. [...]
But some people are happy with their current OS and don't want to
replace it with a completely new one that may not run the other things
they want to run. Common Lisp ought to be analogous to a compiler
plus a library. Sure, some implementations will be in a Lisp-based
OS, but not all of them.
Indeed, it's things like Symbolics Genera that are analogous to
an OS, not Common Lisp.
>You assume that the delivery machine already has UNIX, or MS-DOS, or
>whatever. If you have to deliver your application with an Operating
>System, you would certainly have to pay a license fee for the OS.
>You are buying into the OS, not C, when you use C as your programming
>language.
Um, quite a few people do have machines that already have Unix,
so it's perfectly reasonable to want to deliver applications for
such machines in Lisp just as one could in C.
Most people are not going to change operating systems just to use
Lisp.
>Common Lisp will be an Operating System. When you start
>writing programs that use multiprocessors and parallelism,
>you will rapidly discover that UNIX and C are dead.
Right now, C seems to be winning here rather than losing.
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>In article <·····@dime.cs.umass.edu> ·····@Vega writes:
>>In article <···@paradigm.com> ···@paradigm.com writes:
>>>>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
>>>>
>>>>three costs:
>>>>(1) technical cost of the overly-complex and large runtime portions.
>
>Isn't it a financial cost too? One has to buy larger and more
>powerful machines in order to run Lisp; and such machines cost more.
>For example, I use a ~10 mips, 8 megabyte machine.
This is becoming less and less of an issue; 8-meg machines are not
so uncommon now in the Macintosh world, and in the PC world, such
amounts of memory are accessible via modern environments such as
OS/2 and Windows 3.0. i3/486s and 68030/40s are quite acceptable
both as development and delivery platforms.
>Moreover, I find it really annoying that I can't write little programs
>in Lisp (because they automaticaly become big programs) and have to
>use C instead.
Ahh, but what happens if you write a C program that uses a big library
in an environment that does not support dynamic linking ? Then, you
run into a similar phenomenon, albeit much less drastic. (At Gold Hill,
we estimated the Common Lisp core to cost about 600kbytes of moderately
optimized 286 code.) Again, Lisp functionality like to reside in a
library or OS-core (minus the historically-mandated baggage of
sequence functions and other MacLisp artifacts). Powerful support
is amortized by reuse. The driving impetus is the demand for powerful
programs that are made tractable only by the services that are associated
with Scheme or Common Lisp.
From: Jeff Dalton
Subject: Re: why lisp is dead
Date:
Message-ID: <2230@skye.ed.ac.uk>
In article <····@rice-chex.ai.mit.edu> ···@rice-chex.ai.mit.edu (Robert Krajewski) writes:
>In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>>Isn't it a financial cost too? One has to buy larger and more
>>powerful machines in order to run Lisp; and such machines cost more.
>>For example, I use a ~10 mips, 8 megabyte machine.
>
>This is becoming less and less of an issue; 8-meg machines are not
>so uncommon now in the Macintosh world, and in the PC world [...]
Maybe I should have been clearer. I wasn't trying to say that Common
Lisp needed a ~10 mips 8 megabyte machine; I was trying to say a ~10
mips 8 meg machine wasn't enough:
For example, I use a ~10 mips, 8 megabyte machine. It runs a wide
range of programs written in C without much trouble, but if I want
to use a Common Lisp on it, I usually stick to KCL because larger
ones take a noticable performance hit from paging.
KCL is a fairly small Common Lisp. Consequently, it can run on an 8
meg machine without much paging.
>>Moreover, I find it really annoying that I can't write little programs
>>in Lisp (because they automaticaly become big programs) and have to
>>use C instead.
>
>Ahh, but what happens if you write a C program that uses a big library
>in an environment that does not support dynamic linking ? Then, you
>run into a similar phenomenon, albeit much less drastic.
If I write a C program that uses only a few procedures from a big
library, I still get a small image because the ordinary, non-dynamic
linker includes only the procedures (well, files) that I actually
use.
>(At Gold Hill, we estimated the Common Lisp core to cost about 600kbytes
>of moderately optimized 286 code.)
I'm glad to hear you were able to identify a core of reasonable size.
More implementations should do so.
>Common Lisp will be an Operating System. When you start
>writing programs that use multiprocessors and parallelism,
>you will rapidly discover that UNIX and C are dead.
Unix and C ain't gonna die. Look at this this way: given current
application trends (OOP, complex storage management), environments
that can *provide* what Common Lisp and a carefully pruned subset
of CLOS need will be the wave of the future. The essence of this
functionality is basically Scheme, since much of Common Lisp
(generic sequence functions, math, etc.) can viewed as libraries,
not an essentially computational model.
Such environments will still have to support the many useful programs
that don't need object management. They will probably also have to
partition data and execution privileges in a more disciplined way
than the classic Lisp Machine environment. So what I see coming is
an environment that can support Unix/Posix/OS/2/Mac things, with
new breed of ``application'' that is actually a collection of objects
and classes that augment the basic environment, just as the typical
Lisp Machine program can offer new functions and flavors to other parts
of the machine without recourse to streams, pipes, string analysis,
arbitrary protocols, etc.
From: lawrence.g.mayka
Subject: Re: why lisp is dead
Date:
Message-ID: <15121@cbnewsc.ATT.COM>
In article <····@rice-chex.ai.mit.edu> ···@lammert.ai.mit.edu () writes:
>of CLOS need will be the wave of the future. The essence of this
>functionality is basically Scheme, since much of Common Lisp
>(generic sequence functions, math, etc.) can viewed as libraries,
>not an essentially computational model.
It is true that much of the "bulkiness" of Common Lisp can be
provided as autoloadable libraries, but to imply that the
remainder is nothing more than Scheme stretches the point, I think.
>Such environments will still have to support the many useful programs
>that don't need object management. They will probably also have to
>partition data and execution privileges in a more disciplined way
>than the classic Lisp Machine environment. So what I see coming is
>an environment that can support Unix/Posix/OS/2/Mac things, with
>new breed of ``application'' that is actually a collection of objects
>and classes that augment the basic environment, just as the typical
>Lisp Machine program can offer new functions and flavors to other parts
>of the machine without recourse to streams, pipes, string analysis,
>arbitrary protocols, etc.
In the nearer term, your projection makes a lot of sense. Lisp
machines, for example, are not necessarily the current best choice
for sharing a single processor among multiple potentially hostile
users. But eventually, the overhead of interfacing the older,
non-object-oriented programs to the newer, object-oriented
programs will become more trouble than it's worth, and software
vendors will progressively port their products to the new
environment, adding functionality in the process. The old world
will then take on the characteristics of a "compatibility box,"
appropriate for running "dusty decks" but not for developing new
applications.
This entire technology transition is no different in principle
from others our industry, and other industries, have experienced
over time. As usual, early adopters will assimilate the new
technology first in search of a competitive advantage; more
conservative market players will wait for widespread popularity or
even ubiquity; and stragglers may never make the conversion,
either servicing obsolete systems indefinitely or simply getting
out of the business as it becomes unprofitable.
Do not underestimate the power of standardization. The same
market pressures that are forcing the migration of software
products to the UNIX System (despite the latter's alleged
inapproriateness for some applications) will eventually propel a
movement to its successor. Uniformity of OA&M (operation support,
administration, and maintenance) will of itself be a major
consideration.
This scenario assumes that the new technology will eventually
become competitive in efficiency, cost, etc. with the old (i.e.,
within striking distance for most applications). If that does not
prove to be the case, the two worlds may simply have to learn to
coexist, communicate, and cooperate indefinitely.
Lawrence G. Mayka
AT&T Bell Laboratories
···@ihlpf.att.com
Standard disclaimer.
In article <·····@dime.cs.umass.edu> ·····@Vega writes:
> Common Lisp is quite healthy. In my opinion, the growth of UNIX, C and C++
> is cancerous.
> Common Lisp will be an Operating System. When you start
> writing programs that use multiprocessors and parallelism,
> you will rapidly discover that UNIX and C are dead.
> -Kelly Murray (Top Level, Inc.)
> ······@cs.umass.edu
AT&T has recently announced Concurrent C/C++. As C++ fails to fully
deliver on its promise, CC++ can run interference for a good while.
--
Patrick Logan uunet!mntgfx!plogan | RTFM: Common X-speak meaning
Mentor Graphics Corp. 8500 SW Creekside Pl | "please locate and consult
Beaverton, Oregon 97005-7191 | the relevant documentation".
Sorry. My first attempt to post this failed. When I retried I forgot
to put in the Followup-to field. I wanted to contribute this point,
but I want to keep further C related stuff out of Comp.lang.lisp.
--
Patrick Logan uunet!mntgfx!plogan | RTFM: Common X-speak meaning
Mentor Graphics Corp. 8500 SW Creekside Pl | "please locate and consult
Beaverton, Oregon 97005-7191 | the relevant documentation".
Sorry. My first attempt to post this failed. When I retried I forgot
to put in the Followup-to field. I wanted to contribute this point,
but I want to keep further C related stuff out of Comp.lang.lisp.
--
Patrick Logan uunet!mntgfx!plogan | RTFM: Common X-speak meaning
Mentor Graphics Corp. 8500 SW Creekside Pl | "please locate and consult
Beaverton, Oregon 97005-7191 | the relevant documentation".
Bad day at the Emacs corral. I'm going to stop typing for awhile.
--
Patrick Logan uunet!mntgfx!plogan | RTFM: Common X-speak meaning
Mentor Graphics Corp. 8500 SW Creekside Pl | "please locate and consult
Beaverton, Oregon 97005-7191 | the relevant documentation".
In article <·····@dime.cs.umass.edu>, ·····@Vega writes:
>Common Lisp will be an Operating System. When you start
>writing programs that use multiprocessors and parallelism,
>you will rapidly discover that UNIX and C are dead.
>
>-Kelly Murray (Top Level, Inc.)
> ······@cs.umass.edu
Say what? Having just spent most of a year organizing the POSIX
MutiProcessing Working Group and spending the rest of my time working on
runtime support for Encore's Multimax multiprocessor I find this a striking
remark. We have a QLISP project for our experimental Gigamax and certainly
others in the multiprocesor arena are trying to use Lisp there, but except
for the Connection Machine I know of none where Lisp currently shines and
no plans to provide a multiprocessor "Common Lisp Machine". Do you have
some secrets to share with the rest of us?
--
Bob Knighten
Encore Computer Corp., 257 Cedar Hill Street, Marlborough, MA 01752
Internet: ········@encore.com (508) 460-0500 ext. 2626
uucp: {bu-cs,decvax,gould}!encore!knighten
From: Paul Frederick Snively
Subject: Re: why lisp is dead
Date:
Message-ID: <28960@cup.portal.com>
········@pinocchio (Bob Knighten) writes:
[Stuff expressing amazement at the notion that Lisp-like languages are more
likely to survive the move to a parallel environment than languages like C]
I think the post that got us to this point is being misinterpreted. My
interpretation of it is that functional languages (and really, Common Lisp
hardly qualifies) are easier to parallelize (in the absence of side-effects)
than languages that rely heavily on side-effects are. This is simply a well-
known, mathematically provable fact. However, it does ignore the overwhelming
power of inertia with respect to systems such as UNIX and the C programming
language. In much the same manner as "object-orientedness" can (and has) been
kludged into existing languages such as C, so can (and has, and will) support
for parallelism, I'm sure.
In article <·····@cup.portal.com> ·········@cup.portal.com (Paul Frederick Snively) writes:
>I think the post that got us to this point is being misinterpreted. My
>interpretation of it is that functional languages (and really, Common Lisp
>hardly qualifies) are easier to parallelize (in the absence of side-effects)
>than languages that rely heavily on side-effects are. This is simply a well-
>known, mathematically provable fact.
Those properties arise from the lack of side-effects, not from the
additional baggage of being functional, which may desirable for
other reasons.
Moreover, it is also "easy" to show that side effects are an
efficiency hack; there is often some overhead associated with avoiding
side-effects. Thus, Snively's comment is not that side-effect-free
languages result in faster programs, but that they are easier to
parallelize.
-andy
--
UUCP: {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy
ARPA: ····@neon.stanford.edu
BELLNET: (415) 723-3088
From: Paul Snively
Subject: Re: why lisp is dead
Date:
Message-ID: <7729@goofy.Apple.COM>
In article <······················@Neon.Stanford.EDU>
····@Neon.Stanford.EDU (Andy Freeman) writes:
> In article <·····@cup.portal.com> ·········@cup.portal.com (Paul
Frederick Snively) writes:
> >I think the post that got us to this point is being misinterpreted. My
> >interpretation of it is that functional languages (and really, Common
Lisp
> >hardly qualifies) are easier to parallelize (in the absence of
side-effects)
> >than languages that rely heavily on side-effects are. This is simply a
well-
> >known, mathematically provable fact.
>
> Those properties arise from the lack of side-effects, not from the
> additional baggage of being functional, which may desirable for
> other reasons.
That's exactly right. My point was that since _purely_ functional
languages have no side-effects by definition, they lend themselves to
parallelization.
> Moreover, it is also "easy" to show that side effects are an
> efficiency hack; there is often some overhead associated with avoiding
> side-effects. Thus, Snively's comment is not that side-effect-free
> languages result in faster programs, but that they are easier to
> parallelize.
Also exactly right; I didn't mean to imply any efficiency claims, although
lacking side-effects also means lacking aliasing, which does tend to imply
ease of optimization.
__________________________________________________________________________
Paul Snively
Macintosh Developer Technical Support
Apple Computer, Inc.
1st Choice: ················@gateway.qm.apple.com
2nd Choice: ·········@applelink.apple.com
Last Choice: ·····@apple.com
Just because I work for Apple Computer, Inc. doesn't mean that I believe
what they believe, or vice-versa.
__________________________________________________________________________
In article <······················@Neon.Stanford.EDU> ····@Neon.Stanford.EDU (Andy Freeman) writes:
In article <·····@cup.portal.com> ·········@cup.portal.com (Paul Frederick Snively) writes:
>I think the post that got us to this point is being misinterpreted. My
>interpretation of it is that functional languages (and really, Common Lisp
>hardly qualifies) are easier to parallelize (in the absence of side-effects)
>than languages that rely heavily on side-effects are. This is simply a well-
>known, mathematically provable fact.
Those properties arise from the lack of side-effects,
I will add even something stronger; they do not even arise from the
absence of side effects. The real reason is that by substituting binding
and recursion for assignment and iteration, they effectively force the
use of multiple or parallel assignment, of which binding is a particular
form.
Multiple assignment in the general case is both easy to parallelize and
has remarkably simple formal properties. In particular, if you use a
number of single assignments equivalent to a single multiple assignment,
you have to prove implictly the equivalence, which can be hard; example:
a[i], i := i, a[i]
This can be expanded in a series of simple assignments, via the use of
temporaries, but proving that the simple line above does interchange i
and a[i] is easy, proving it for the block of simple assignments is not
easy.
It is utterly surprising how many tough bits of code become trivial when
written using multiple assignment (see an old CACM paper on pointer
rotation and sliding for partial examples); and I have a contention that
this happens in all those cases where use of binding is advocated by
side-effect free advocates.
Moreover, it is also "easy" to show that side effects are an
efficiency hack; there is often some overhead associated with avoiding
side-effects.
I have an algorithm (to be published) that can break up into several
single assignments, to be executed either in parallel or serially, for
any kind of multiple assignment. It uses the minimum (or greater if
higher parallelism is desired) number of temporaries needed. What
happens is that binding arguments to parameters is equivalent to a
multiple assignment with the largest possible number of temporaries,
which is inefficient. In languages like C on RISC style machines people
spend a lot of compiler effort on avoiding such copies where the
parameter does not get modified, by way of inteprocedural analysis...
not from the additional baggage of being functional, which may
desirable for other reasons.
The ability to build function and control abstractions (functionals, non
nested flow, ...) is very important, and desirable, but totally
unrelated, as you say, to what is IMNHO the red herring issue of
side-effect freedom.
In practice I am very hard pressed to think of languages other than Lisp
and its siblings that do allow function and control abstraction in a
grand way. Maybe SL-5, but... Lisp is not dead. Scheme even less so.
--
Piercarlo "Peter" Grandi | ARPA: ·················@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: ···@cs.aber.ac.uk
In article <·····@encore.Encore.COM>, ········@pinocchio (Bob Knighten) writes:
> ... We have a QLISP project for our experimental Gigamax and certainly
> others in the multiprocesor arena are trying to use Lisp there, but except
> for the Connection Machine I know of none where Lisp currently shines ...
I think Mul-T, a Scheme dialect with futures, "shines". It runs on Multimaxen
multiprocessors, it runs fast (native code Orbit compiler), and it is available
free (anon. ftp from wheaties.ai.mit.edu) right now. I believe that Encore even
distributes Mul-T for a nominal fee.
Randy Osborne
In article <····@crltrx.crl.dec.com> ···@oz.crl.dec.com (Randy Osborne) writes:
>I think Mul-T, a Scheme dialect with futures, "shines".
Yeah, but it's a real shame about the name. Why didn't they call their
parallel dialect of Scheme "Par-T"?
"Another missed opportunity". Sigh.
--
Paul Dourish, Rank Xerox EuroPARC, Cambridge UK <················@Xerox.com>
"Ain't they got no barbers where you come from, boy?"
Hello George,
Lisp is not dead or dying. On Unix machines, Lisp is doing extremely
well, not just as a development tool, but for delivery as well. Franz
as a company is healthy and growing rapidly which makes us believe
that the Unix Lisp market is also healthy and growing. Companies like
NeXT, Cray, Sun, Apollo, DEC, Sequent and IBM all openly endorse Lisp
on their Unix machines. So if Lisp is dying, it must be in other
circles (LMs, DOS?).
Your points about delivery are well taken. I would argue that the
main problem with runtime is with the size of the Lisp and the expense
of the delivery platform rather than the cost of runtime licenses and
the administrative costs. All of these, fortunately, are being dealt
with now by various Lisp vendors. It helps too, that hardware is
still getting less expensive and more powerful.
In Allegro CL 4.0 and in Lucid/Sun CL 4.0 you will have affordable
runtime systems, affordable in both machine resources and in price.
Both are due out this year. Lucid/Sun CL will use tree-shaking
algorithm while Franz will take a very different approach. In either
case, the point is the same; Lisp vendors are dealing with the issue
of delivery in a big way and working to reduce the size of the
deliverable.
Lisp runtime licenses (from Franz, I can't quote others) today cost
from $100 to $600 on typical Unix machines. This is more than C and
Fortran, but it isn't that much considering what is provided to you
with Lisp. With Lisp you get lots more functionality, with lots of
features and customizable options not found in C. Lisp is also
getting more and more portable and is much faster now than ever
before. Lisp is still best suited for maintaining and writing large
complex applications. For some smaller, simpler projects, C is
admittedly more appropriate at the current time. But this will change
and you will see more and more Lisp-based deliverables.
If the cost of Lisp runtimes are too much for you, you can opt for
some free or very inexpensive alternatives (KCL, Ibuki, PD-Franz..).
We don't expect all C-based companies to switch to Lisp or vice versa.
Lisp has its niche, and as software gets more powerful and
complicated, that niche will grow. Lisp is not dead. It is alive and
kicking, even in the commercial world.
Regards,
Bill Carlson
Franz Inc.
·······@franz.com
--
=========================================================================
Bill Carlson Franz Inc.
1995 University Avenue, Suite 275
INTERNET: ·······@franz.com Berkeley, CA 94704
UUCP: uunet!franz!carlson 415-548-3600, FAX:415-548-8253