I'm concerned that Java may be a threat to the future of Lisp
(including Scheme).
I'm not talking about Java the language, threatening Lisp by being
better in some way -- in the past, Lisp has been able to neutralize
such threats just by evolving or adding features.
Instead I'm talking about Java the CPU architecture, threatening
Lisp by slowing it to a crawl. I'm not an expert on the Java
Virtual Machine but from what I've heard, it sounds like it's the
exact opposite of a Lisp machine: a processor architecture that
pessimizes the performance of Lisp, compared to other languages
(and compared to Lisp on a general-purpose processor).
Java VM may become ubiquitous. Java CPU chips may become as numerous
as television sets, outnumbering even Intel 80x86 chips. Even if
that doesn't happen there will be Java VM emulators everywhere,
and lots of re-usable code that runs on them. Will programmers
avoid Lisp, if it can't be implemented efficiently on such a popular
CPU architecture? Will software buyers and publishers insist on
programs that run well on a "Net Computer" with a Java CPU?
Recently I heard that Sun has asked ANSI (or was it ISO?) to
standardize Java. This is our chance. Representatives of the Lisp
community could join the standardization effort, and lobby hard
for Lisp-friendly features (or at least Lisp-neutral features) to
be added to the JVM instruction set.
It may be that certain capabilities of Lisp conflict fundamentally
with byte-code verification. Even if that is true, we should still
be able to make use of the Java VM and libraries to achieve
portability and compatibility in situations where verification is
not an issue (e. g., programs like Word Perfect that are not run
inside of a Web browser). But only if we're not slowed to a crawl.
Sincerely,
-- Robert Munyer <······@mcs.com>
P. S. Does anyone know Guy Steele's e-mail address? I'd like to
CC him a copy of this article, or at least call his attention to
this thread.
On 4/4/1997, Cyber Surfer <············@wildcard.demon.co.uk> wrote:
> The JVM may be the ultimate commercial "black box" for delivering
> code. IMHO it's too early to say what can't be done this way, while
> the list of things already being done is impressive enough! We may be
> wondering how we coped for so long without it, a few years from now.
On 4/5/1997, MENARD Steve <······@JSP.UMontreal.CA> wrote:
> I have just finished writing a Scheme->JVM backend for the Gambit-C
> system, so I can tell you whay some features lacking in the JVM
> make it hard, if not impossible, to write efficient translators.
From: David Gadbois
Subject: Re: Will Java VM kill Lisp? How to fight it.
Date:
Message-ID: <5ibnqp$pbm$1@news3.texas.net>
Robert Munyer <······@MCS.COM> wrote:
>I'm concerned that Java may be a threat to the future of Lisp
>(including Scheme).
>I'm not talking about Java the language, threatening Lisp by being
>better in some way -- in the past, Lisp has been able to neutralize
>such threats just by evolving or adding features.
>
>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.
In a sense, this "memory wall" that folks have been fretting about
lately is just what makes Java itself practical. Barring some amazing
new development that reduces memory latency a lot, any hardware action
that will get around the problem will be at a systems level (see,
e.g., http://www.tera.com/) that can only help everybody.
2. I have not seen any proposals for "Java" CPUs that only implement
the Java Virtual Machine. Rather, they have support for some of the
JVM instructions in addition to "normal" instructions. After all,
they have to be able to run those massive libraries well, and
implementing them requires things you can't do in the JVM.
3. Given current technology constraints, I can't think of a good
excuse to do a special Java-supporting CPU for execution speed
reasons. It is justifiable for bumming system cost or power
consumption, or even for marketing communications reasons. But it
does not make much business sense to go for Java-specific features in
the performance market.
--David Gadbois
In article <············@news3.texas.net>,
David Gadbois <·······@cyc.com> wrote:
>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.
That's exactly the problem. The JVM does not allow efficient memory use
in Java programs.
>2. I have not seen any proposals for "Java" CPUs that only implement
>the Java Virtual Machine. Rather, they have support for some of the
>JVM instructions in addition to "normal" instructions. After all,
>they have to be able to run those massive libraries well, and
>implementing them requires things you can't do in the JVM.
Great. So when you ship your Lisp in JVM code over the Internet, how do you
get access to those other instructions?
>3. Given current technology constraints, I can't think of a good
>excuse to do a special Java-supporting CPU for execution speed
>reasons. It is justifiable for bumming system cost or power
>consumption, or even for marketing communications reasons. But it
>does not make much business sense to go for Java-specific features in
>the performance market.
It doesn't really matter. If most code runs in a JVM on top of other
processors, it will be slow if the JVM does not support Lisp
constructs efficiently. Who cares what the actual CPU looks like?
Paul Prescod
[hbaker: the reason for cross-posting comp.arch should be clear.]
In article <············@news3.texas.net>, ·······@cyc.com (David Gadbois)
wrote:
> Robert 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.
> 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.
A CMOS gate dispates most of its power during switching. This translates
to charge moving into the off gate turning it on and vice versa. Perhaps
as switching speeds pass the GHz range, power dissapation will become a
major design issue in even the high end "toaster" boxes.
Jeff
From: Joseph H Allen
Subject: Re: Will Java VM kill Lisp? How to fight it.
Date:
Message-ID: <E8v1LE.CI@world.std.com>
In article <··········@nntpb.cb.lucent.com>,
Neil Kirby <···@atlas.cb.lucent.com> wrote:
>In article <·······················@10.0.2.1>,
>Henry Baker <······@netcom.com> wrote:
>>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.
Someone has to invent "regenerative breaking" for logic switches. I.E.,
there should be some way to reuse the energy which has to be discharged from
those gate and parasitic capacitors. Perhaps little switching power
supplies distributed around the chip which dump the charge back into the
power supply. This could probably done pretty easily if you have a large
enough noise margin... I don't know if it would be efficient enough to help
very much.
>In MOS, switching involves a voltage swing and dumping currents generated
>from parasitic capacitance as heat. Do it more often and you get more
>heat per unit time. Use a lower voltage and it switches faster and dumps
>less heat.
I think it's more complicated than that. Sure you have less charge with a
lower voltage, but you also have lower on resistance. In 4000 series CMOS
for example, higher voltage certainly means faster. My guess is that if you
took one of those 2.5V cpus, hooked it up to a big refrigerator and ran it
at 5V, it would run much faster. Only when you hit the heat constraint does
lower voltage imply higher speed. So: package those chips in copper instead
of ceramic for lower junction thermal resistance :-)
·······@world.std.com (Joseph H Allen) wrote:
>In article <··········@nntpb.cb.lucent.com>,
>Neil Kirby <···@atlas.cb.lucent.com> wrote:
>>In article <·······················@10.0.2.1>,
>>Henry Baker <······@netcom.com> wrote:
>
>>>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.
>
>Someone has to invent "regenerative breaking" for logic switches. I.E.,
>there should be some way to reuse the energy which has to be discharged from
>those gate and parasitic capacitors. Perhaps little switching power
>supplies distributed around the chip which dump the charge back into the
>power supply. This could probably done pretty easily if you have a large
>enough noise margin... I don't know if it would be efficient enough to help
>very much.
Possibly using an AC+DC power supply, synchronous with the clock rate? In
this way, at clock transitions, the supply voltage (and therefore the
energy dissipation) would be low, while the switching is controlled by
charge stored on the opposite transition while the supply voltage was high,
therefore maintaining noise immunity. Unwanted stored charge would be
returned to the PSU in the right phase without any need to step it up to a
higher voltage.
The chip would appear to the power supply as a fairly large capacitor,
resonating with an inductor (or a number of distributed inductors).
Thus instead of fighting capacitance with resistance (which is dissipative)
the aim is to fight it with inductance, from which we can recover the
energy.
The design may have to maintain the capacitance at a fairly constant value,
which may require differential switching.
In EMC terms, while the CPU may resemble a small transmitter, at least the
harmonic content should be relatively low...
- Brian
From: Tony Griffiths
Subject: Recycling energy; was "Will Java VM kill Lisp?"
Date:
Message-ID: <335C281C.6675@OntheNet.com.au>
> >>>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.
> >
> >Someone has to invent "regenerative breaking" for logic switches. I.E.,
> >there should be some way to reuse the energy which has to be discharged from
> >those gate and parasitic capacitors. Perhaps little switching power
> >supplies distributed around the chip which dump the charge back into the
> >power supply. This could probably done pretty easily if you have a large
> >enough noise margin... I don't know if it would be efficient enough to help
> >very much.
OK, here's an idea... Why not recycle all that heat energy by using the
temp gradient/thermocouple affect to generate electricity. All you need
is a sufficiently large mass of cool matter to provide the gradient!
Hey, I know! The swimming pool out the back will do. Kill one bird
with three stones. Cool the computer, recycle the waste heat, AND swim
all year round! ;-))
Put in a spar and you're really "cookin' with gas!", or should that read
"Intel PentiumPro-1000 inside"!
Sorry! Couldn't help myself... ;-)
Tony
In article <·············@OntheNet.com.au> Tony Griffiths
<·····@OntheNet.com.au> writes:
> Hey, I know! The swimming pool out the back will do. Kill one bird
> with three stones. Cool the computer, recycle the waste heat, AND swim
> all year round! ;-))
You think you're joking, don't you? :-)
My previous company seriously considered having a heated swimming pool
for the employees as a heat sink (large building with lots of solar
gain to air condition plus humungous dinosaur pen, oops, machine room,
full of big iron and washing machines and a power supply into the site
of 3/4 megawatt). The economics of building the pool were no problem,
the only killer was the running costs - keeping an Olympic sized pool
heated pool clean enough for humans is expensive. :-(
--
This message is Mime compatible - it can coexist with lying dwarves
who sing in German.
Tony Griffiths <·····@OntheNet.com.au> writes:
>
> > >>>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.
> > >
> > >Someone has to invent "regenerative breaking" for logic switches. I.E.,
> > >there should be some way to reuse the energy which has to be discharged from
> > >those gate and parasitic capacitors. Perhaps little switching power
> > >supplies distributed around the chip which dump the charge back into the
> > >power supply. This could probably done pretty easily if you have a large
> > >enough noise margin... I don't know if it would be efficient enough to help
> > >very much.
>
Actually, there's some work on this being done at ISI. Check out the
ACMOS group's web page at http://w3.isi.edu/acmos/acmos-homepage.html.
- Bert Kay
There was also an article in US Wired Magazine about 3 months ago about
this (I believe). Didnt understand a word of it, but basically it was
reusing the energy involved in switching.
Cheers,
Winton
·······@world.std.com (Joseph H Allen) writes:
> Someone has to invent "regenerative breaking" for logic switches. I.E.,
> there should be some way to reuse the energy which has to be discharged from
> those gate and parasitic capacitors. Perhaps little switching power
> supplies distributed around the chip which dump the charge back into the
> power supply. This could probably done pretty easily if you have a large
> enough noise margin... I don't know if it would be efficient enough to help
> very much.
I think someone (at MIT and where else was it?) is already working on
that. From what I heard they resonate the switching power.
> I think it's more complicated than that. Sure you have less charge with a
> lower voltage, but you also have lower on resistance. In 4000 series CMOS
> for example, higher voltage certainly means faster. My guess is that if you
> took one of those 2.5V cpus, hooked it up to a big refrigerator and ran it
> at 5V, it would run much faster. Only when you hit the heat constraint does
> lower voltage imply higher speed. So: package those chips in copper instead
> of ceramic for lower junction thermal resistance :-)
Wouldn't fly for several reasons. The trick with cooling is being
developed for desktop systems by a company called KryoTech
http://www.kryotech.com a spinoff of an NCR research effort. You
definitely don't want to up the supply voltage, though.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: ·····@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
>Recently I heard that Sun has asked ANSI (or was it ISO?) to
>standardize Java. This is our chance. Representatives of the Lisp
>community could join the standardization effort, and lobby hard
>for Lisp-friendly features (or at least Lisp-neutral features) to
>be added to the JVM instruction set.
>
This is lunacy. ISO is not a political body that you
can beg or bribe into adding pie-in-the-sky features to
a proposed standard.
--
My home page: http://www.andromeda.com/people/ddyer/home.html
From: ·····················@pobox.com
Subject: Re: Will Java VM kill Lisp? How to fight it.
Date:
Message-ID: <ppwbu7q5rwz.fsf@m10-250-1.MIT.EDU>
In article <······················@192.0.2.1> ·····@netcom.com (Dave
Dyer) writes:
>>Recently I heard that Sun has asked ANSI (or was it ISO?) to
>>standardize Java. This is our chance. Representatives of the Lisp
>>community could join the standardization effort, and lobby hard
>>for Lisp-friendly features (or at least Lisp-neutral features) to
>>be added to the JVM instruction set.
>>
>This is lunacy. ISO is not a political body that you
>can beg or bribe into adding pie-in-the-sky features to
>a proposed standard.
these wouldn't be pie-in-the-sky additions, but rather additions that
would make the java VM more useful than it is now. it's currently
tuned to run java code, without much consideration of other
languages. it could be extended in such a way that it was still just
as efficient at running java code and also had support for running
other languages efficiently.
for an example of such additions, check out:
http://www.ai.mit.edu/people/shivers/javaScheme.html
ray jones
In response to the many who point out my obvious ignorance
of the standard-setting process; you're probably right, and that's
why so many "standards" are so wedged.
--
My home page: http://www.andromeda.com/people/ddyer/home.html
Dave Dyer <·····@netcom.com> wrote in article
<······················@192.0.2.1>...
>
> In response to the many who point out my obvious ignorance
> of the standard-setting process; you're probably right, and that's
> why so many "standards" are so wedged.
>
You are absolutely correct! Also, this is why standards that begin with a
solid base document are so much more likely to be successful than those
that do not (and I have the lumps to prove it). FWIW, if Sun can provide
ANSI with a decent base document, an ANSI/ISO Java spec is likely to be a
slam dunk, as such things go.
Anyway, an ANSI standard might have trouble preventing any inadvertent
dissing of Lisp running on a Java VM. This is because any ANSI Java
standard would be a _language_ standard: not a spec for a standardized VM,
but merely a spec for how the ANSI Java language ought to behave in any
conforming product. It's a subtle, but telling, distinction.
Bill House
--
······@dazsi.com
http://www.dazsi.com
"Bill House" <······@dazsi.com> writes:
>Anyway, an ANSI standard might have trouble preventing any inadvertent
>dissing of Lisp running on a Java VM. This is because any ANSI Java
>standard would be a _language_ standard: not a spec for a standardized VM,
>but merely a spec for how the ANSI Java language ought to behave in any
>conforming product. It's a subtle, but telling, distinction.
If there can be ISO standards for network protocols, why _can't_ there be
an ISO standard for a VM? If there can be a standard for something like
the ASN.1 Encoding Rules (how to convert data to bytes and back again),
why can't there be a standard for a byte-code? If the ISO APL standard
can include a byte-level specification of portable workspaces (yep, APL
got there before Java did), why not a standard for Java byte-codes?
For the life of my I cannot see any reason why there cannot be TWO
standards:
- Java-the-language; allowing non-VM targets
- JVM-the-byte-code-instruction-set; allowing non-Java sources.
Note that a "conforming" Java presumably has to accept *some* form of
.class file, so it is anything but clear that the byte codes wouldn't
be in the language standard.
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote in article
<············@goanna.cs.rmit.edu.au>...
>
[snip]
>
> If there can be ISO standards for network protocols, why _can't_ there be
> an ISO standard for a VM? If there can be a standard for something like
> the ASN.1 Encoding Rules (how to convert data to bytes and back again),
> why can't there be a standard for a byte-code? If the ISO APL standard
> can include a byte-level specification of portable workspaces (yep, APL
> got there before Java did), why not a standard for Java byte-codes?
>
There might be a way, but I don't think it would be an X3 committee (the
group that brought you the ANSI C standard, etc.). X3 specializes in
computer programming languages, like H3 specializes in database languages
(a la SQL). By ANSI definitions, I believe the Java VM is a product, not a
language. FWIW, most ANSI programming language standards try to abstain
from dictating the precise form of vendor products, so as not to stifle
competition.
NIST, for example, might object vociferously to byte-level specifications.
When this came up in X3J19, I remember the NIST rep going on about machines
with 9-bit words, etc. These things can be hotly contested, even though the
fate of such odd-ball architectures may seem irrelevant to those of us
working in the so-called mainstream.
ISO is a different body altogether, but they have the so-called
"fast-track", where existing national standards (like those produced by
ANSI) are adopted without the need to independently develop an ISO version.
Of course, this places considerable additional work on the project editor,
to ensure conformance with all applicable style guides. It's really quite a
bit of work, and much of it has little to do with the technology itself.
<sigh>
Anyway, I wish them luck.
Bill House
--
······@dazsi.com
http://www.dazsi.com
Bill House <······@dazsi.com> wrote:
> There might be a way, but I don't think it would be an X3 committee (the
> group that brought you the ANSI C standard, etc.). X3 specializes in
> computer programming languages...
X3J specializes in languages. X3, on the other hand, has a much
broader scope. For example, the X3.64-1979 standard for terminals
was based on the DEC VT100 command set, X3T9.2 is concerned with
the SCSI-2 interface (among others), and X3S3.3 is concerned with
the network and transport layers of the Internet Protocol (IP).
X3 could standardize the Java VM if that were desirable.
Will
Thanks for the clarification, my mistake. See my question in a previous
post.
>
> X3 could standardize the Java VM if that were desirable.
>
Do you think that VM standardization is desireable? There are obvious
benefits to Lisp, if the result is sufficiently flexible to efficiently
handle more than one family of languages.
OTOH, I tend to think that the delivery system, i.e. browser embedding, is
more exciting than the Java VM itself. Is the Java VM a state-of-the-art
32-bit VM?. It would be a shame to standardize on the VM in such a way
that only allowed Java-like languages to be efficient, or that even stunted
the future efficiency of Java itself.
Personally, I think it may be too soon to standardize the VM. Rather than
trying to shoehorn high-performance language neutrality into a Java VM
standard, perhaps the VM-based, Web-delivered language market ought to
evolve a bit more, so that an eventual VM standard can have sufficient
motivation to accomodate a broader set of semantics. Users might be better
served by simply having an X3J langauge standard for Java.
Bill House
--
······@dazsi.com
http://www.dazsi.com
From: Barry Margolin
Subject: Re: Should JVM be Standardized? (was Re: X3J is only part of X3)
Date:
Message-ID: <5immnk$89l@tools.bbnplanet.com>
In article <··························@wjh_dell_133.dazsi.com>,
Bill House <······@dazsi.com> wrote:
>Do you think that VM standardization is desireable? There are obvious
>benefits to Lisp, if the result is sufficiently flexible to efficiently
>handle more than one family of languages.
Java VM standardization is desirable so that anyone can implement a
Java-capable browser or compile their favorite language into Java applets.
Without a standard for the byte code representation of Java, much of the
promise of Java is lost. Do you want to see Java become like HTML, with
vendors running off and implementing their own, incompatible flavors? If
that were to happen with Java it would be disastrous; at least with HTML
it's relatively easy to ignore unrecognized tags, but I doubt that this
would be feasible with byte codes.
Whether it's appropriate to standardize it *now*, when there has been so
little experience with it, and whether we should standardize on something
similar to the current de facto standard, which only supports Java well,
are the more appropriate questions. But those issues can be dealt with
*within* the standardization process -- once a committee is formed, the
first thing it does is specify its timeline and charter.
--
Barry Margolin
BBN Corporation, Cambridge, MA
······@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
Barry Margolin <······@bbnplanet.com> wrote in article
<··········@tools.bbnplanet.com>...
>
> Whether it's appropriate to standardize it *now*, when there has been so
> little experience with it, and whether we should standardize on something
> similar to the current de facto standard, which only supports Java well,
> are the more appropriate questions. But those issues can be dealt with
> *within* the standardization process -- once a committee is formed, the
> first thing it does is specify its timeline and charter.
>
And the 2nd thing they usually do is forget both and proceed with their
special interests. <sad smile>
Anyway, I would be a supporter of the right bytecode standard for a
portable VM, but such an animal might be very different than the current
Java VM. However, that does not mean that an acceptable standard could not
be formulated that would satisfy the concerns of all involved.
It's not just the future of Java, or even Lisp, but also the greater issue
of agent-oriented programming. If a standard VM could support both Java
applets and Lisp agents (and I say Lisp because most AOP work now is in
Lisp dialects), then it would be a boon to everyone. OTOH, if I had to
trade one for the other, I think that AOP has a lot more upside than Java
alone and that an improved standard for HTML would make a fine basis for
writing portable GUIs.
BTW, on the bit about cross-platform portability of Java apps -- why not
have mobile programs carry their own execution environment with them?
Instead of just having downloadable content (i.e. applets), have the
browsers expose a common VM API that multiple VMs can plug into. That way,
it's not required for the standardized VM to be efficient for every
possible language.
Bill House
--
······@dazsi.com
http://www.dazsi.com
Barry Margolin <······@bbnplanet.com> wrote in article
<··········@tools.bbnplanet.com>...
> In article <··························@wjh_dell_133.dazsi.com>,
> Bill House <······@dazsi.com> wrote:
> >Do you think that VM standardization is desireable? There are obvious
> >benefits to Lisp, if the result is sufficiently flexible to efficiently
> >handle more than one family of languages.
>
> Java VM standardization is desirable so that anyone can implement a
> Java-capable browser or compile their favorite language into Java
applets.
> Without a standard for the byte code representation of Java, much of the
> promise of Java is lost. Do you want to see Java become like HTML, with
> vendors running off and implementing their own, incompatible flavors? If
> that were to happen with Java it would be disastrous; at least with HTML
> it's relatively easy to ignore unrecognized tags, but I doubt that this
> would be feasible with byte codes.
>
> Whether it's appropriate to standardize it *now*, when there has been so
> little experience with it, and whether we should standardize on something
> similar to the current de facto standard, which only supports Java well,
> are the more appropriate questions. But those issues can be dealt with
> *within* the standardization process -- once a committee is formed, the
> first thing it does is specify its timeline and charter.
> --
> Barry Margolin
> BBN Corporation, Cambridge, MA
> ······@bbnplanet.com
> (BBN customers, call (800) 632-7638 option 1 for support)
>
BTW, it has been brought to my attention that I dropped a very important J
-- X3J is the body that specializes in languages, whereas X3 has a broader
scope. Kinda ironic, but my fault.
Is the effort to standardize Java being taken on at both the language and
VM levels?
Bill House
--
······@dazsi.com
http://www.dazsi.com
From: Per Bothner
Subject: Re: Will Java VM kill Lisp? How to fight it.
Date:
Message-ID: <5ioicl$fvs$1@rtl.cygnus.com>
The Java VM (specifically the format of bytecodes and .class
files) is not just a matter of implementation. It is part of
the specification of the Java language, as defined in "The
Java Language Specification." Specifically, the standard method:
Class java.lang.ClassLoader.definedClass(byte[], int, int)
takes a byte array that "should have the format of a valid class
file as defined by the 'Java Virtual Machine Specification.'"
Of course, one could standardize "stand-alone" or "embedded" Java to
not include Class.definedClass, while "hosted" Java would include it.
--
--Per Bothner
Cygnus Solutions ·······@cygnus.com http://www.cygnus.com/~bothner
I missed the beginning of this discussion. Could someone please tell
me, or point me in the direction to, why the Java VM cannot
efficiently run languages like Lisp and Scheme?
Thanks in advance,
Robert
--
Robert Virding Tel: +46 (0)8 719 95 28
Computer Science Laboratory Email: ··@erix.ericsson.se
Ericsson Telecom AB
S-126 25 �LVSJ�, SWEDEN
WWW: http://www.ericsson.se/cslab/~rv
"Folk s�ger att jag inte bryr mig om n�gonting, men det skiter jag i".
>these wouldn't be pie-in-the-sky additions, but rather additions that
>would make the java VM more useful than it is now. it's currently
>tuned to run java code, without much consideration of other
>languages. it could be extended in such a way that it was still just
>as efficient at running java code and also had support for running
>other languages efficiently.
I dont question the value of such additions to Java from
the viewpoint of those whose primary adjenda is NOT Java,
but from the viewpoint of those for whom it is, having the
Java VM and the Java standard optimized to run Java is a
good thing.
Suppose some Cobol fanatics came nosing around the ANSI
Lisp committee, with a list of proposed additions to make
Lisp more punch-card friendly. What kind of reception do
you imagine they'd get?
More seriously, the job of the standards committee is to
ensure uniformity; and in view of the *many* java implementations
in existance or in progress, I'm sure the last thing on their
mind is to specify completely new functionality to make Java
a better language.
--
My home page: http://www.andromeda.com/people/ddyer/home.html
Dave Dyer <·····@netcom.com> wrote in article
<······················@192.0.2.1>...
>
> This is lunacy. ISO is not a political body that you
> can beg or bribe into adding pie-in-the-sky features to
> a proposed standard.
>
Ahem, I think perhaps you've not spent much time at ANSI/ISO technical
committee meetings. All it takes to get your favorite feature into/out of a
standard is to show up at the meetings, pay the membership dues, and
politic enough other committee members into voting with you.
Bill House
Former ANSI XJ19 Project Editor
--
······@dazsi.com
http://www.dazsi.com
·····@netcom.com (Dave Dyer) writes:
>This is lunacy. ISO is not a political body that you
>can beg or bribe into adding pie-in-the-sky features to
>a proposed standard.
What planet do _you_ live on?
On _this_ planet, the Prolog standard was held up for *years*
because everyone was fighting to put in their own pet approach
instead of asking what people were actually _using_.
You should ask over in comp.lang.fortran about the politics-
ridden history of Fortran 90.
ISO doesn't develop standards.
ISO *committees* develop standards.
And they _are_ political bodies, and finance _does_ matter.
Finance matters because you have be a member of the
committee to have *timely* effect, and you have to go to
meetings in various countries and take time off work.
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: William Clodius
Subject: Re: Will Java VM kill Lisp? How to fight it.
Date:
Message-ID: <334A5E58.6201@lanl.gov>
Richard A. O'Keefe wrote:
>
> <snip>
> You should ask over in comp.lang.fortran about the politics-
> ridden history of Fortran 90.
> <snip>
The politics of F90 is not often discussed in that forum. Those that
are knowledgeable on the topic don't want to reopen old wounds. A
better source of information is Brian Meeks article
http://www.kcl.ac.uk/kis/support/cc/staff/brian/forsaga.html
Brian's publications are a good place to start for information on
language standardization issues in general
http://www.kcl.ac.uk/kis/support/cc/staff/brian/brianpub.html
Also of interest is the special issue, Computer Standards and
Interfaces Vol 16 Nos 5/6, September 1994, which discusses the language
standards activities of ISO over the period from 1983-1993. The
importance of politics in all the standards revealed in this issue is
very discouraging, e.g., the consequences of IBM's failure to support
aspects of the PL/I and APL standards, the excessive conservatism of
the initial Pascal proposal, Borland's failure to support the Pascal
standards, the wild swings in the draft Fortran 8x standard, the
failure of the Japanese and Germans to compromise on their Lisp
proposals, etc.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
From: Erik Naggum
Subject: Re: Will Java VM kill Lisp? How to fight it.
Date:
Message-ID: <3069476504597905@naggum.no>
* Dave Dyer
| This is lunacy. ISO is not a political body that you can beg or bribe
| into adding pie-in-the-sky features to a proposed standard.
yes, it is. this is how many features get into standards. it happens all
the time, even with non-"information technology" standards.
(I have long worked with standards in ISO/IEC JTC 1/SCs 2, 18, and 22, and
have been an accredited member of ISO/IEC JTC 1/SC 18/WG 8. your lunacy is
fact, and is also the reason I couldn't stomach it for very long.)
#\Erik
--
I'm no longer young enough to know everything.
From: Robert Munyer
Subject: Re: Will Java VM kill Lisp? How to fight it.
Date:
Message-ID: <5ie1th$ala$1@Venus.mcs.net>
In article <···············@m10-250-1.mit.edu>,
<·····················@pobox.com> wrote:
> these wouldn't be pie-in-the-sky additions, but rather additions
> that would make the java VM more useful than it is now. it's
> currently tuned to run java code, without much consideration of
> other languages. it could be extended in such a way that it was
> still just as efficient at running java code and also had support
> for running other languages efficiently.
>
> for an example of such additions, check out:
> http://www.ai.mit.edu/people/shivers/javaScheme.html
Shivers' article, and the Fahlman article it links to, are great.
I have one thing to add.
There's a chance (I have no idea how big) that technical and/or
political realities will make it impossible (at least in the short
term) for us to get fast JVM Lisp on an equal footing with Java,
with our programs trusted to self-download from a Web page and
execute without the user's permission.
But even if that turns out to be the case, it would still be valuable
to have non-trusted, fast Lisp code that runs only with the user's
permission.
Implementing this could be as simple as adding a few general-purpose
instructions that would change the JVM into what Shivers calls "a
generic RISC instruction set," and accepting them only in programs
that have been granted "everything" permission by the user.
My suggestion (not that I claim it; many others have thought of it
I'm sure) seems to have two disadvantages, compared to Shivers'
and Fahlman's ideas:
1. We couldn't put self-downloading fast JVM Lisp code on Web pages.
But we could still do it with slow JVM Lisp code, which is all
we can do now anyway.
2. We'd be implementing things like method dispatch in the extended
JVM byte-code. So even our "fast" code might be somewhat slower
than Java. But I suspect the just-in-time JVM compilers would
help minimize this disadvantage.
My plan also has some advantages:
1. Probably easier to implement.
2. Possibly easier to get it accepted by the committee.
3. Under Fahlman's plan a Lisp vendor would have to provide several
versions of the VM-extension code, at least one for each type
of hardware platform.
In conclusion I don't think my plan is the best, but I think it
would be a good fallback if we couldn't get one of the better ones
approved. We can always work for something better later -- but I
think it's important to try to get at least this small improvement
written into the first JVM spec that's an actual standard.
Sincerely,
-- Robert Munyer <······@mcs.com>
The right technical solution for portability and speed
is to simply send LISP SOURCE CODE to the client.
By using ascii text compression, it is even MORE compact
than java byte codes. As high-level source code,
there is no "security" nonsense like JVM must do,
the lisp functions that can be executed on the client would
simply be "safe". The client can just interpret the source code
directly, or do a byte-compile, or do a native code compile.
The only downside is that everyone can see your source code.
This is actually a huge advantage, so people can see
all the fancy stuff you can do by looking at the source,
just the way HTML itself become so widespread.
Anyway, reverse jvm compilers are already available, so that disadvantage
is not really a valid concern. And since it is transmitted in
compressed form, only a real executing client will see the actual source
if so desired.
This is old technology really.
But we all know that great technology always takes a back seat,
and momentum and marketing are in the drivers seat.
The Java VM will not kill Lisp, certainly not any more
than it is seen as dead already.
In fact, it gives Lisp more visibility.
In my view, it's not what's running on the client anyway,
all the real programming work is going to run on the server,
and there Lisp can actually win.
-Kelly Murray ···@franz.com http://www.franz.com
In article <············@sparky.franz.com>, Kelly Murray <···@franz.com> wrote:
>The right technical solution for portability and speed
>is to simply send LISP SOURCE CODE to the client.
How do you ensure that the client has a Lisp interpreter (or JIT compiler)?
The advantage of compiling Lisp to JVM byte codes is that most of the
popular browsers support it, so the users don't have to do anything special
to be able to execute your code.
I suppose you could implement the Lisp interpreter in Java; you'd send the
interpreter applet followed by the code for it to interpret. However, I
wouldn't expect to win any speed awards from such a configuration.
>By using ascii text compression, it is even MORE compact
>than java byte codes. As high-level source code,
>there is no "security" nonsense like JVM must do,
>the lisp functions that can be executed on the client would
>simply be "safe". The client can just interpret the source code
>directly, or do a byte-compile, or do a native code compile.
You're right that Lisp is safe w/r/t features like pointers and other
direct machine access features (they simply don't exist). But you'll still
have your work cut out for you defining safe libraries for I/O, networking,
interprocess communications, etc. (although much of the work can simply be
copied from the Java safe runtime spec).
--
Barry Margolin
BBN Corporation, Cambridge, MA
······@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
In article <··························@wjh_dell_133.dazsi.com> "Bill House" <······@dazsi.com> writes:
From: "Bill House" <······@dazsi.com>
Newsgroups: comp.lang.lisp,comp.lang.scheme
Date: 11 Apr 1997 07:55:33 GMT
Organization: DAZ Systems, Inc.
Lines: 43
X-Newsreader: Microsoft Internet News 4.70.1155
Xref: agate comp.lang.lisp:26676 comp.lang.scheme:19573
Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote in article
<············@goanna.cs.rmit.edu.au>...
>
[snip]
>
> If there can be ISO standards for network protocols, why _can't_ there be
> an ISO standard for a VM? If there can be a standard for something like
> the ASN.1 Encoding Rules (how to convert data to bytes and back again),
> why can't there be a standard for a byte-code? If the ISO APL standard
> can include a byte-level specification of portable workspaces (yep, APL
> got there before Java did), why not a standard for Java byte-codes?
>
There might be a way, but I don't think it would be an X3 committee (the
group that brought you the ANSI C standard, etc.). X3 specializes in
computer programming languages, like H3 specializes in database languages
(a la SQL). By ANSI definitions, I believe the Java VM is a product, not a
language. FWIW, most ANSI programming language standards try to abstain
from dictating the precise form of vendor products, so as not to stifle
competition.
This is now a moot point, and of course I am speaking without knowing
the detailed process that led to ANSI CL. HOWEVER! The fact that the
ANSI CL does not contain provisions for at least a standard
multiprocessing substrate (not to speak of standard FFI and windowing
substrate) and the current substantial comments by the Java advocates
read over here , make me think that "stifling the competition" would
have been a very good thing in the case of CL.
Happy Lisping
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
Robert Munyer 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'm not an expert on the Java
> Virtual Machine but from what I've heard, it sounds like it's the
> exact opposite of a Lisp machine: a processor architecture that
> pessimizes the performance of Lisp, compared to other languages
> (and compared to Lisp on a general-purpose processor).
The sentence there is key. To run lisp efficently on general-
purpose machines, there are many compilation techniques. Many of these
techniques should also make lisp run efficently in the JVM.
> Recently I heard that Sun has asked ANSI (or was it ISO?) to
> standardize Java. This is our chance. Representatives of the Lisp
> community could join the standardization effort, and lobby hard
> for Lisp-friendly features (or at least Lisp-neutral features) to
> be added to the JVM instruction set.
The only one I can think of would be to add the ability to call a
pointed-to function.
We could dream up more friendly constructs, such as 'add the top 2
things on the stack, whatever they are' but I think that wouldn't fit
too well into the java security model.
I think people interested in lisp should look at the java craze as an
opportunity. The JVM could be a great target architecture. If a *good*
lisp->JVM compiler can be produced, you could have cross-platform lisp
apps with a portable gui. If you can be more productive than the java
programmers, and produce the same result, lisp would take over.
> It may be that certain capabilities of Lisp conflict fundamentally
> with byte-code verification.
I can't think of any. Perhaps someone else can?
With a mighty <·············@nospan.netright.com>,
·····@nospan.netright.com uttered these wise words...
> I think people interested in lisp should look at the java craze as an
> opportunity. The JVM could be a great target architecture. If a *good*
> lisp->JVM compiler can be produced, you could have cross-platform lisp
> apps with a portable gui. If you can be more productive than the java
> programmers, and produce the same result, lisp would take over.
This is my attitude, too. Java isn't "bad news for Lisp", any more
than C or C++. There are Lisp compilers that generate C code, and
there are features (or lack of features) in C that should make this
hard to do, and yet it's still possible.
I don't doubt that there may be _some_ Lisp features that don't
translate well into JVM bytecodes, which we could either see as a
challenging problem to solve, or perhaps an opportunity to re-evaluate
those features. It might not be necessary for a Lisp->JVM compiler to
support _every_ Lisp feature, but I dunno. If it is, then I'm sure
someone will find a practical solution.
Lisp has come in many forms, and I won't be suprised if the existing
dialects are not the Last Word. A "JLisp" dialect, working with the
JVM, might be a little different from CL/Scheme/XLISP/etc. I'd hope
that it would at least include functions/classes/methods that access
the standard Java classes.
That alone might qualify as a "JLisp" dialect! Variants of CL and
Scheme for the JVM could be called JCL and JSCM. I wonder...
Would a CPU designed for Java be so different? If such a beast created
problems for Lisp, it might not be alone. On the other hand, some
people have claimed that a lot of existing CPUs were designed for C
(I have my doubts about that), and yet that wasn't a big problem for
non-C languages.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note the "gubbish" in my email address.
I have yet to be convinced that the JVM will retain the priveleged
position it currently has in Java.
In the interests of getting Java speeds up there are a number of
alternatives such as the Oberon/Juice approach. The classloader model
permits a lot of flexibility in mapping the output of the compiler to
the native machine architecture.
I also doubt that chip manufacturers are going to easily adopt the
same architecture.
It may be a naiive position, but lisp will probably outlast Java.
This is an obvious, old, but yet unresolved issue. I have little useful to
add, but just to make sure that "everyone here" is aware of 1) Kawa, a
Scheme compiler written in Java that targets jvm, and 2) Sun has clearly
acknowledged that the vm is too Java specific and that they will consider
bounded extensions, but nothing seems to be happening along those lines.
The .class file has several 16 bit limitations. We (and Sun, really) might
hope for these to be limiting factors soon, so as to provide more push for
vm revision.
p. 5 of the red book, if I may call it that: "The Java Virtual Machine was
designed to support the Java programming language."
p. 3: "Attracted by a generally available, machine independent platform,
implementors of other languages are turning to the Java Virtual Machine as
a delivery vehicle for their languages. In the future, we will consider
bounded extensions to the Java Virtual Machine to provide better support
for other languages."
Also, kawa does not implement general tail recursion, but I'm not sure if
this is a result of it being difficult to allow defines anywhere, or the
fact that jvm's function call stack isn't exposed.
I think the only the language, not the vm is being standardized. Of course,
Sun (and others) would probably lobby against things that don't fit well
with existing vm's.
- Jay
Robert Munyer <······@MCS.COM> wrote in article
<············@Jupiter.Mcs.Net>...
> I'm concerned that Java may be a threat to the future of Lisp
> (including Scheme).
>
"Jay Krell" <·········@cornell.edu> writes:
> Also, kawa does not implement general tail recursion, but I'm not sure if
> this is a result of it being difficult to allow defines anywhere, or the
> fact that jvm's function call stack isn't exposed.
as i understand it, the java vm doesn't support tail recursion. each method
invocation creates its own environment and returns take you back one level.
essentially, continuations are completely hidden from view.
i'd love to be corrected on this. any thoughts?
-itai
In article <············@Jupiter.Mcs.Net>,
Robert Munyer <······@MCS.COM> wrote:
>I'm concerned that Java may be a threat to the future of Lisp
>(including Scheme).
>
>I'm not talking about Java the language, threatening Lisp by being
>better in some way -- in the past, Lisp has been able to neutralize
>such threats just by evolving or adding features.
>
>Instead I'm talking about Java the CPU architecture, threatening
>Lisp by slowing it to a crawl. I'm not an expert on the Java
>Virtual Machine but from what I've heard, it sounds like it's the
>exact opposite of a Lisp machine: a processor architecture that
>pessimizes the performance of Lisp, compared to other languages
>(and compared to Lisp on a general-purpose processor).
The physical CPU is not relevant. It is the features of the
CPU (generalized or Java-specific) that are relevant. I agree with
you that as the JVM becomes a more and more important "platform",
Lisp will be at a disadvantage compared to Java, and some Java-like
languages. I think one way to attack this is to define and
implement efficient Lisp-style language support to publically
available JVMs, like GNU's Kaffe. Running code is the Law of the
Internet.
I was hoping that ISO would be the place to add support for
other languages to the JVM, but my impression is that
Java will be standardized under a new "improved" process that
basically rubber-stamps defacto standards, rather than going
through the usual ISO process.
"Providing the capability of accepting standard solutions to IT problems
that have been developed outside JTC 1 has been a significant step in
JTC 1, and we are delighted that the process is being used."
I believe that standardizing this VM without thinking of other languages
(not just Lisp) would be a huge step backwards.
Paul Prescod