Newsgroups: comp.lang.lisp,comp.lang.scheme,comp.arch
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!goldenapple.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!news.dfci.harvard.edu!camelot.ccs.neu.edu!news.mathworks.com!news-peer.sprintlink.net!news-peer.sprintlink.net!news.sprintlink.net!sprint!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!ais.net!ix.netcom.com!hbaker
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Will Java VM kill Lisp?  How to fight it.
Content-Type: text/plain; charset=ISO-8859-1
Message-ID: <hbaker-0804971551430001@10.0.2.1>
Sender: hbaker@netcom16.netcom.com
Content-Transfer-Encoding: 8bit
Organization: nil
X-Newsreader: Yet Another NewsWatcher 2.2.0
References: <5ibcks$hvf$1@Jupiter.Mcs.Net> <5ibnqp$pbm$1@news3.texas.net>
Mime-Version: 1.0
Date: Tue, 8 Apr 1997 23:51:43 GMT
Lines: 34
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:26503 comp.lang.scheme:19397 comp.arch:76526

[hbaker: the reason for cross-posting comp.arch should be clear.]

In article <5ibnqp$pbm$1@news3.texas.net>, gadbois@cyc.com (David Gadbois)
wrote:
> Robert Munyer <munyer@MCS.COM> wrote:
> >I'm concerned that Java may be a threat to the future of Lisp (including
> >Scheme).
[snip]
> >Instead I'm talking about Java the CPU architecture, threatening
> >Lisp by slowing it to a crawl.
> 
> I would not be concerned about this for several reasons:
> 1. CPU architecture does not matter as much as it used to and will
> matter less in the future.  Memory speed increases have not kept up
> with CPU ones, and the trend is likely to continue.  CPU's spend more
> and more of their time twiddling their electronic thumbs waiting for
> the data to arrive, and fast Java CPUs can potentially make good use
> of this time going through whatever wacky contortions are necessary to
> run Lisp codes.

I think that this argument falls into the trap recently sprung on the
'memory costs are constant because they haven't fallen for the last
5 years' people.  When memory costs resumed their usual precipitous
decline, a lot of people were caught holding the bag.

Gilder's 'slow gates are beautiful' idea has recently become self-fulfilling.
If complex architectures can't take advantage of fast gates due to the
communications delays of long wires, and the stultifying effects of deep
pipelining, then no one will push very hard to get faster gates.

The current assumption is that fast necessarily means 'hot' (in temperature
and dissipation), although I can find nothing in my physics books that even
remotely implies this connection.  It's time to wipe the slate clean, and get
some new ideas into this industry.
