Java vs lisp (was: Re: Prolog vs. Lisp)
Fergus Henderson
ja...@harlequin.co.uk (Jason Trenouth) writes:
>Java, while admirable in many respects, is a very poor substitute for Common
>Lisp:
>
> no function pointers
> no closures
> no multiple inheritance
> no multiple dispatch
> no macros
> no arbitrary precision arithmetic (*)
> no restarts
> no real dynamism (you still have to cast for pity's sake)
> etc
Function pointers and closures can be simulated without _that_ much
trouble using interfaces. Java does allow multiple inheritence of
interfaces. Multiple dispatch is also something that can be simulated
in the language, although probably not as conveniently as in Common
Lisp (I don't know how Common Lisp handles it). Yes, you do miss out
on macros, but macros have disadvantages as well as advantages. As you
yourself point out, arbitrary precision arithmetic can be (and probably
has been) done in a Java library. Is "restarts" a feature of common
lisp the language, or is that an implementation-specific thing?
Certainly Java implementations are not as mature as Common Lisp
implementations. If saving and restarting programs were a feature that
is strongly in demand, then I'm sure some Java implementations would
have it soon. I don't know what you mean by "no real dynamism".
There is also no doubt a list that is probably about as long as the one above
of things that you can do in Java but not in common lisp.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Erik Naggum
* Jason Trenouth
| Java, while admirable in many respects, is a very poor substitute for Common
| Lisp:
|
| no function pointers
| no closures
| no multiple inheritance
| no multiple dispatch
| no macros
| no arbitrary precision arithmetic (*)
| no restarts
| no real dynamism (you still have to cast for pity's sake)
| etc
at various times, people have been claiming that syntax means nothing, that
all programming languages are Turing equivalent, or that there is value in
repeating similar tautologies, so my take on this is that they all boil
down to an issue of pragmatics, since the arguments translate to "you can,
with some effort, fake everything in one language in every other language".
the issue of pragmatics becomes important only when considering the amount
of work required to implement something that some other language gives you
at much lower cost. in the final analysis, the same CPU must be executing
a sequence of instructions, taken from the same instruction set, resulting
from compiling any and all the languages out there, but we don't discuss
the merits of machine languages these days. I guess the _only_ reason is
that people who still argue about how much feature X can be "simulated" in
language L don't really want to take their argument all the way.
* Fergus Henderson
| Function pointers and closures can be simulated without _that_ much
| trouble using interfaces. Java does allow multiple inheritence of
| interfaces. Multiple dispatch is also something that can be simulated in
| the language, although probably not as conveniently as in Common Lisp (I
| don't know how Common Lisp handles it). As you yourself point out,
| arbitrary precision arithmetic can be (and probably has been) done in a
| Java library.
you admit that on the pragmatics scale, Java loses on all these points.
| Yes, you do miss out on macros, but macros have disadvantages as well as
| advantages.
what an amusing argument.
| Is "restarts" a feature of common lisp the language, or is that an
| implementation-specific thing?
restarts are a fundamental part of the Common Lisp condition system.
| If saving and restarting programs were a feature that is strongly in
| demand, then I'm sure some Java implementations would have it soon.
I think it would have added credibility to your argument if you had asked
what a `restart' in Common Lisp is.
| There is also no doubt a list that is probably about as long as the one
| above of things that you can do in Java but not in common lisp.
really? you know, it's kinda hard to believe you're the right person to
say that after your above stunt with restarts. how about _supplying_ this
list if it "no doubt" exists? in the face of one _actual_ list, where your
response is that users have to _simulate_ the features in Java, hand-waving
"no doubt" about a similar list the other way is pretty lame. but since
this is posted to comp.lang.java.advocacy, what's to expect? *sigh*
#\Erik
--
I'm no longer young enough to know everything.
Jason Trenouth
On 3 Apr 1997 00:42:13 GMT, f...@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
> ja...@harlequin.co.uk (Jason Trenouth) writes:
>
> >Java, while admirable in many respects, is a very poor substitute for Common
> >Lisp:
> >
> > no function pointers
> > no closures
> > no multiple inheritance
> > no multiple dispatch
> > no macros
> > no arbitrary precision arithmetic (*)
> > no restarts
> > no real dynamism (you still have to cast for pity's sake)
> > etc
>
> Function pointers and closures can be simulated without _that_ much
> trouble using interfaces.
So I have to give up on both the notational convenience and the efficiency?
What's the point of saying it can be done? (*)
> Java does allow multiple inheritence of
> interfaces.
But not implementations.
> Multiple dispatch is also something that can be simulated
> in the language, although probably not as conveniently as in Common
> Lisp (I don't know how Common Lisp handles it).
See (*) above.
> Is "restarts" a feature of common
> lisp the language, or is that an implementation-specific thing?
The language. I believe (correct me if I'm mistaken) that in Java, the stack
is unwound _before_ a handler runs. This makes some kinds of recovery much
clumsier than in Common Lisp, where the handler can run with all the context
of the signaller.
> I don't know what you mean by "no real dynamism".
In this case I meant sometimes having to explicitly tell the compiler what the
type is (via a cast) in order get something to work (again, correct me if I'm
misinformed). In languages like Common Lisp and Dylan, adding explicit typing
doesn't change the semantics of the program: it only improves its performance
or error checking.
> There is also no doubt a list that is probably about as long as the one above
> of things that you can do in Java but not in common lisp.
I still contest that Java is a poor substitute for Common Lisp. If there were
a list of Java-only features then it would simply mean that the converse also
held. Both can be true without any contradiction.
__Jason
Bruce Tobin
Fergus Henderson wrote:
>
> ja...@harlequin.co.uk (Jason Trenouth) writes:
>
> >Java, while admirable in many respects, is a very poor substitute for Common
> >Lisp:
> >
> > no function pointers
> > no closures
> > no multiple inheritance
> > no multiple dispatch
> > no macros
> > no arbitrary precision arithmetic (*)
> > no restarts
> > no real dynamism (you still have to cast for pity's sake)
> > etc
>
> Function pointers and closures can be simulated without _that_ much
> trouble using interfaces.
The examples I've seen require 20 or so lines of code to do the work of
one. OTOH the Pizza compiler adds closures to Java without requiring any
changes to the JVM (Pizza code compiles into regular Java code). Now if
someone could get Symantec, Borland, Asymetrix, or someone to support
the Pizza extensions in an IDE..
> Java does allow multiple inheritence of
> interfaces.
Not the same as MI. The brain-dead implementation of MI in C++ has
unfairly tarnished its reputation; as implemented in Lisp, Eiffel,
Sather, or Dylan, MI is a very useful feature.
> Multiple dispatch is also something that can be simulated
> in the language, although probably not as conveniently as in Common
> Lisp (I don't know how Common Lisp handles it).
Yes, and you can simulate polymorphism in COBOL; wouldn't want to have
to write an application that way, though.
> Yes, you do miss out
> on macros, but macros have disadvantages as well as advantages.
I suspect you're thinking of C macros, which are a whole different (and
vastly inferior) animal. Lisp macros are far more flexible and
powerful, and permit techniques which solve most of the problems
associated with simple string-replacement macros.
> Is "restarts" a feature of common
> lisp the language, or is that an implementation-specific thing?
Restarts are a feature of the language, defined in the ANSI
specification.
> I don't know what you mean by "no real dynamism".
You can't create classes at runtime, add members to classes at runtime,
change the inheritance of a class at runtime.. (there's a lot more to
say here, but an exhaustive list of the dynamic features of CLOS would
take several pages and some research on my part).
>
> There is also no doubt a list that is probably about as long as the one above
> of things that you can do in Java but not in common lisp.
>
No, there isn't. I know this sounds dogmatic, but Common Lisp is almost
insanely flexible. You can, if you like, redesign the entire object
model. Read "The Art of the Meta-Object Protocol" (MIT Press, 1991).
The only thing (and it's an important point, I'll admit) you can do in
Java but not in Lisp is:
Sell your project to management.
Brian N. Miller
Jason Trenouth wrote:
>
> I still contest that Java is a poor substitute for Common Lisp.
I suspect your complaints are against the java language, and not
the jvm. Writing a lisp interpreter that targets the jvm has
already been done more than once. So you can write applets in
lisp and market them as java code.
David Hanley
Erik Naggum wrote:
>
> at various times, people have been claiming that syntax means nothing, that
> all programming languages are Turing equivalent,
I don't think anyone extends this argument to mean 'all languages are
equal'.
> * Fergus Henderson
> | Function pointers and closures can be simulated without _that_ much
> | trouble using interfaces. Java does allow multiple inheritence of
> | interfaces. Multiple dispatch is also something that can be simulated in
> | the language, although probably not as conveniently as in Common Lisp (I
> | don't know how Common Lisp handles it). As you yourself point out,
> | arbitrary precision arithmetic can be (and probably has been) done in a
> | Java library.
>
> you admit that on the pragmatics scale, Java loses on all these points.
I don't think so. One has to bear in mind that in diffrent languages,
one uses different models. In java, I'm not likely to design my program
around features that don't exist.
>
> | Yes, you do miss out on macros, but macros have disadvantages as well as
> | advantages.
>
> what an amusing argument.
Exactly how is it amusing?
> I think it would have added credibility to your argument if you had asked
> what a `restart' in Common Lisp is.
Why don't you tell us?
>
> | There is also no doubt a list that is probably about as long as the one
> | above of things that you can do in Java but not in common lisp.
>
> really? you know, it's kinda hard to believe you're the right person to
> say that after your above stunt with restarts. how about _supplying_ this
> list if it "no doubt" exists?
Well, let's take a shot at it:
1) Portable binaries.
2) Run-in-the browser models.
3) Secure executable model.
4) True basic types( efficency consideration ).
5) Built-in graphical user interface model( portable ).
6) *Very* elegant and powerful threading model.
7) Interfaces.
8) Simple foreign function interface.
9) Object serilization.
10) Remote method invocation.
11) Robustness of a static type checker
Now, you could do some of these things in lisp, but I refer you to your
earlier pragmatics model.
Also, please note that I'm not claiming that java is 'better' than
lisp. I have no interest in that, and I think such things are best
decided by the target domain of the application.
> in the face of one _actual_ list, where your
> response is that users have to _simulate_ the features in Java,
A better list might have showed some examples, and asked how the same
task might be carried out. If the original list were a valid mothod of
discussion, I could post some assembler tricks, and smugly ask how it
would be done in lisp. It would mean nothing related to the current
discussion, much like the original list.
Marco Antoniotti
In article <ddyer-03049...@192.0.2.1> dd...@netcom.com (Dave Dyer) writes:
From: dd...@netcom.com (Dave Dyer)
Newsgroups: comp.ai,comp.lang.java.advocacy,comp.lang.lisp
Date: Thu, 3 Apr 1997 19:21:18 GMT
Organization: Andromeda Software
Path: agate!newsxfer3.itd.umich.edu!howland.erols.net!ix.netcom.com!NewsWatcher!user
Sender: dd...@netcom20.netcom.com
References: <3340DF...@netvision.net.il> <3341B6...@felix.cc.gatech.edu> <nagleE7...@netcom.com> <3365440d.698147468@newshost> <5huud5$f...@mulga.cs.mu.OZ.AU>
Lines: 42
Xref: agate comp.ai:45660 comp.lang.java.advocacy:7728 comp.lang.lisp:26352
Lets not just sling mud; all languages have their good and
bad points, and many of them are not absolute but dependant
on the intended application.
Java and Common lisp share these advantages over most other languages:
Garbage colleciton
Strong memory protection
Object orientation
Modern exception handling
Introspection (in java 1.1)
Common lisp is clearly superior in these areas:
Macros
Multiple inheritance
Runtime semantics checking.
Java is clearly superior in these areas:
Portability, Deliverability, Availability.
I would say that Common Lisp is as portable as Java.
Compile time semantics checking
CMUCL is pretty good in that respect too.
Automaticly generated documentation
The fact that ther is not a single tool to do this does not mean that
CL cannot be used for automated generated documentation. As a matter
of fact, doc strings are kept in the runtime.
Dynamic linking (ability to distribute small, independant packages)
This should be qualified. All CL are "dynamic linkers" in a certain
way. I suppose you are referring to "shared" libraries or DLL's in MS
parlance.
Connectivity to the outside world.
This is not very qualified either. What do you mean.
Common lisp has these major problems:
30 years of baggage it can't jettison
"monolithic" runtime model.
poor connectivity to anything non-lisp.
If there where two major developers of Java instead of one and each of
them had developed its own flavor of 'native' interface, we would be
saying the same for Java. The truth is that, given an implementation
of Common Lisp, its "connectivity to anything non lisp" (which means
C) is very wel defined and developed.
lack of common graphics system.
This is a sore point that is again the consequence of having more than
one vendor with different agendas.
Java has these major problems:
Lack of macros, multiple inheritance
Lack of dynamic un-linking
Poor graphics subsystem.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
Erik Naggum
* Brian Rogoff
| Java has multithreading facilities built into the language. While there
| are certainly Lisps, notably EuLisp, which also have built in threads,
| ANSI Common Lisp does not. This may be important to some people.
can you draw a line between Java the language and Java the implementation
the same way the Common Lisp guys had to draw that line? if you can't,
don't you think it's grossly unfair to compare the two infavorably as long
as there are implementations that support everything you ask for? I do.
#\Erik
--
Brian Rogoff
On Thu, 3 Apr 1997, Bruce Tobin wrote:
<... much stuff, all of which I agree with, deleted ...>
> No, there isn't. I know this sounds dogmatic, but Common Lisp is almost
> insanely flexible. You can, if you like, redesign the entire object
> model. Read "The Art of the Meta-Object Protocol" (MIT Press, 1991).
> The only thing (and it's an important point, I'll admit) you can do in
> Java but not in Lisp is:
>
> Sell your project to management.
Java has multithreading facilities built into the language. While
there are certainly Lisps, notably EuLisp, which also have built in
threads, ANSI Common Lisp does not. This may be important to some people.
With respect to the JVM, it penalizes other languages whose
constructs do not map so naturally to it, so a Common Lisp on the JVM
would likely suck. OTOH, a Lisp could be designed specifically for the
JVM; there is already a Scheme on the JVM and that would be a good place to
start.
-- Brian
Dave Dyer
Lets not just sling mud; all languages have their good and
bad points, and many of them are not absolute but dependant
on the intended application.
Java and Common lisp share these advantages over most other languages:
Garbage colleciton
Strong memory protection
Object orientation
Modern exception handling
Introspection (in java 1.1)
Common lisp is clearly superior in these areas:
Macros
Multiple inheritance
Runtime semantics checking.
Java is clearly superior in these areas:
Portability, Deliverability, Availability.
Compile time semantics checking
Automaticly generated documentation
Dynamic linking (ability to distribute small, independant packages)
Connectivity to the outside world.
Common lisp has these major problems:
30 years of baggage it can't jettison
"monolithic" runtime model.
poor connectivity to anything non-lisp.
lack of common graphics system.
Java has these major problems:
Lack of macros, multiple inheritance
Lack of dynamic un-linking
Poor graphics subsystem.
--
My home page: http://www.andromeda.com/people/ddyer/home.html
Ivan
>
>>Java, while admirable in many respects, is a very poor substitute for Common
>>Lisp:
>>
>> no function pointers
>> no closures
Er, check out inner classes in Java 1.1. The name is misleading.
nested classes? anonymous classes? big deal.
But you can "return" your anonymous nested class (er object) sort of
like a lambda and all variables within the constructors lexical scope
will be properly available, even tho the original frame has long
gone away. If that isn't the essence of a closure I don't know what is.
Brian Rogoff
On 3 Apr 1997, Erik Naggum wrote:
> * Brian Rogoff
> | Java has multithreading facilities built into the language. While there
> | are certainly Lisps, notably EuLisp, which also have built in threads,
> | ANSI Common Lisp does not. This may be important to some people.
>
> the same way the Common Lisp guys had to draw that line? if you can't,
> don't you think it's grossly unfair to compare the two infavorably as long
> as there are implementations that support everything you ask for? I do.
I don't understand your point. Java has multithreading as part of
the language standard. See
http://www.javasoft.com/doc/language_specification/17.doc.html
if you don't believe me. This is a fact. Whether or not you like the
particular choice of multithreading primitives, and whether or not extant
implementations support it fully, is not what I am arguing. ANSI Common
Lisp has no primitives for multithreading. That Franz, Harlequin, and
others may provide multithreaded implementations is also outside the scope
of my argument, but I certainly don't think I was "grossly unfair". The
thread packages in Common Lisp implementations are vendor specific. Do you
dispute this?
PS -- I am aware that CLIM provides some basic multi-processing
functionality.
-- Brian
Rainer Joswig
In article <3343CD...@pcisys.net>, "Brian N. Miller"
<bmi...@pcisys.net> wrote:
> Jason Trenouth wrote:
> >
> > I still contest that Java is a poor substitute for Common Lisp.
>
> I suspect your complaints are against the java language, and not
> the jvm. Writing a lisp interpreter
Few are really interested in INTERPRETERS these days.
> that targets the jvm has
> already been done more than once. So you can write applets in
> lisp and market them as java code.
The limitations of the Java virtual machine for supporting Lisp and
similar languages (Smalltalk, Prolog, ...) makes it hard
to implement these languages efficiently (this was the last
thing I have heard on this topic). SUN has built a *Java* virtual
machine - and not a more universal VM. Sigh.
Rob Mayoff
Jason Trenouth wrote:
> The language. I believe (correct me if I'm mistaken) that in Java, the stack
> is unwound _before_ a handler runs. This makes some kinds of recovery much
> clumsier than in Common Lisp, where the handler can run with all the context
> of the signaller.
Yes, for exception handlers Java has termination semantics, not
resumption semantics. See "The Design and Evolution of C++" (by Bjarne
Stroustrup), section 16.6. He discusses at length why they choose
termination semantics for C++ (and the reasons given include significant
real-world experience with both kinds of semantics). All the same
arguments apply for Java.
> > I don't know what you mean by "no real dynamism".
>
> In this case I meant sometimes having to explicitly tell the compiler what the
> type is (via a cast) in order get something to work (again, correct me if I'm
> misinformed). In languages like Common Lisp and Dylan, adding explicit typing
> doesn't change the semantics of the program: it only improves its performance
> or error checking.
The fact that you have to sometimes specify a cast isn't (IMHO) a
reduction of dynamism, and it allows static type-checking. You still
get dynamic binding, which is "real dynamism".
Jay Martin
iv...@Eng.Sun.COM (Ivan) writes:
>>
>>>Java, while admirable in many respects, is a very poor substitute for Common
>>>Lisp:
>>>
>> no function pointers
>>> no closures
>Er, check out inner classes in Java 1.1. The name is misleading.
>nested classes? anonymous classes? big deal.
>But you can "return" your anonymous nested class (er object) sort of
>like a lambda and all variables within the constructors lexical scope
>will be properly available, even tho the original frame has long
>gone away. If that isn't the essence of a closure I don't know what is.
I have just looked at these features and I am sickened. Looks like
the Java designers are now violating their own principles (simplicity
and language design based on software engineering principles) and are
starting to "lose it". To quote their own opinion about these features
"... it is trivial to write code that is torture to read....people who
read your code can become confused trying to keep track of what piece of
which class's method's code they are reading, and what the outer
context is. Use this tool sparingly. ... When its not, it's awful."
How many more gratutitous and "awful code" generating features are
they going to add?
I think my anticipation for Java has just decreased.
Jay
Jay Martin
iv...@Eng.Sun.COM (Ivan) writes:
>>
>>>Java, while admirable in many respects, is a very poor substitute for Common
>>>Lisp:
>>>
>>> no function pointers
>>> no closures
>Er, check out inner classes in Java 1.1. The name is misleading.
>nested classes? anonymous classes? big deal.
>But you can "return" your anonymous nested class (er object) sort of
>like a lambda and all variables within the constructors lexical scope
>will be properly available, even tho the original frame has long
>gone away. If that isn't the essence of a closure I don't know what is.
I have just looked at these features and I am sickened. Looks like
the Java designers are now violating their own principles (simplicity
and language design based on software engineering principles) and are
starting to "lose it". To quote their own opinion about these features
"... it is trivial to write code that is torture to read....people who
read your code can become confused trying to keep tack of what pice of
Fergus Henderson
ja...@harlequin.co.uk (Jason Trenouth) writes:
>I still contest that Java is a poor substitute for Common Lisp. If there were
>a list of Java-only features then it would simply mean that the converse also
>held. Both can be true without any contradiction.
I understand and agree.
But usually one is looking for a programming language that will get the
job done, no looking for "a substitute for Common Lisp" or "a substitute
for Java". For most tasks, if you look at the big picture then I think
Java would be a good substitute for Common Lisp, even though on a
feature-by-feature basis some Java features may be poor substitutes for
the equivalent Commoon Lisp features. I don't think the converse is true,
because the features which Java has that Common Lisp doesn't (e.g.
portable GUI, multithreading, browser security model, etc.) are a lot
harder to simulate.
Fergus Henderson
Erik Naggum <er...@naggum.no> writes:
>* Brian Rogoff
>| Java has multithreading facilities built into the language. While there
>| are certainly Lisps, notably EuLisp, which also have built in threads,
>| ANSI Common Lisp does not. This may be important to some people.
>
>can you draw a line between Java the language and Java the implementation
>the same way the Common Lisp guys had to draw that line?
Yes, you can. Java the language is defined by the Java Language
Specification.
Fergus Henderson
Erik Naggum <er...@naggum.no> writes:
>since this is posted to comp.lang.java.advocacy, what's to expect? *sigh*
I think a .advocacy group is the right place to discuss language comparisons.
A .advocacy group doesn't have do be devoted to mindless religious tracts.
It is possible to have useful technical discussions in such groups.
Are you suggesting that serious technical language comparisons are
impossible? Are you suggesting that those interested in serious
technical discussion should abandon .advocacy groups? If people
interested in serious technical discusssions wish to disuss language
comparisons, where better to discuss them?
Fergus Henderson
Bruce Tobin wrote:
>
> The examples I've seen require 20 or so lines of code to do the work of
> one. OTOH the Pizza compiler adds closures to Java without requiring any
> changes to the JVM (Pizza code compiles into regular Java code). Now if
> someone could get Symantec, Borland, Asymetrix, or someone to support
> the Pizza extensions in an IDE..
Yeah, Pizza is much nicer, I agree.
> > Yes, you do miss out
> > on macros, but macros have disadvantages as well as advantages.
>
> I suspect you're thinking of C macros, which are a whole different (and
> vastly inferior) animal. Lisp macros are far more flexible and
> powerful, and permit techniques which solve most of the problems
> associated with simple string-replacement macros.
I know that lisp macros work on s-expressions, not on strings.
(Hey, even C macros work on tokens, not strings...)
I'm not very familiar with lisp macros, but I imagine that they are
probably pretty similar to something that I am quite familiar with,
namely Prolog's de facto standard `term_expansion' feature, which is
preprocessing at the level of Prolog terms.
Even processing things at a that level, term_expansion macros
share quite a few of the problems of C macros, including
added tempatation to invent inscrutable new languages that no-one
else will understand, difficulty of source-level debugging, etc.
> The only thing (and it's an important point, I'll admit) you can do in
> Java but not in Lisp is:
>
> Sell your project to management.
;-)
Erik Naggum
* Erik Naggum
| can you draw a line between Java the language and Java the implementation
| the same way the Common Lisp guys had to draw that line?
* Fergus Henderson
| Yes, you can. Java the language is defined by the Java Language
| Specification.
the important issue in this regard is that Common Lisp was an effort to
standardize what _could_ be standardized among vendors of other Lisps
(before CLtL) and Common Lisp (after CLtL). lack of agreement on a
multi-processing system excluded it from the standard, although every
vendor has their version of it. the same goes for many other things.
Java had the luxury of being specified and implemented by the same vendor.
the difference between "language" and "implementation" is thus a question
of how much you can agree with yourself to make part of the language.
Erik Naggum
* David Hanley
| I don't think so. One has to bear in mind that in diffrent languages,
| one uses different models. In java, I'm not likely to design my program
| around features that don't exist.
which is, I believe, _the_ point. the weak Sapir-Worf hypothesis states
that it is hard to think about that for which you do not have a language.
(the strong Sapir-Worf hypothesis states that you cannot, but this must be
wrong, considering that new languages and words are created.)
| > | Yes, you do miss out on macros, but macros have disadvantages as well
| > | as advantages.
| >
| > what an amusing argument.
|
| Exactly how is it amusing?
imagine it generalized to other things that have "disadvantages as well as
advantages", i.e., everything -- somehow, this is an argument in favor of
_not_ supporting it. as such, it is completely devoid of meaning, it is
ridiculous on its face. ("no, we're sorry, you car can't have an engine
because engines have disadvantages as well as advantages.") this argument
can be used about anything by anyone with impunity -- it requires no
accountability of those who employ it -- _everything_ has "disadvantages as
well as advantages", especially if this is left to people who are somewhat
fuzzy on exactly what is being requested. (it appears that Fergus is
thinking in terms of C's macro system, which has severely restricted
functionality. better macro systems existed before C got its variety.)
| > I think it would have added credibility to your argument if you had
| > asked what a `restart' in Common Lisp is.
|
| Why don't you tell us?
I did.
"restarts are a fundamental part of the Common Lisp condition system."
when an operation fails, the programmer can request certain actions from
the exception handler that would rectify the situation and effectively
restart the attempted computation. typically, the exception handler would
invoke the debugger, which would present the user with some choices and
accept an answer.
| Well, let's take a shot at it:
considering that Java is optimized for certain uses, let's look at what you
can get from Common Lisp systems that try to address the same needs.
| 1) Portable binaries.
several Common Lisp implementations offer portable byte-code binaries, as
well. one outstanding example is Bruno Haible's CLISP implementation.
another, not Common Lisp, but proof positive that "portabel binaries"
existed before Java was conceived, is GNU Emacs. however, most Lisp
vendors and users find that execution speed is important enough to merit
native compilation. this is also true of Java, I hear, so we're debating
implementations.
| 2) Run-in-the browser models.
Java doesn't run in the browser. JVM byte-code does. JVM is intentionally
crippled, but Scheme->JVM compilers exist. as an execution target, nothing
prohibits Common Lisp to compile to it, only nobody has done so.
| 3) Secure executable model.
ahem. please see comp.risks and the trade magazines for the precise value
of "secure" which makes "secure" a feature of Java.
| 4) True basic types (efficency consideration).
this is something Common Lisp does not have? the mind boggles.
| 5) Built-in graphical user interface model (portable).
granted. remove "built-in", and Common Lisp systems support various GUIs.
stick with one vendor's choice, and you're as far as you get with Java.
| 6) *Very* elegant and powerful threading model.
all the commercial Common Lisp implementations provide multiprocessing.
again, stick with one vendor, and you're as far as you get with Java.
| 7) Interfaces.
granted. as a language construct, this is neat.
| 8) Simple foreign function interface.
again, true for any particular Common Lisp vendor. not standardized
because of the much wider variety of languages to talk to when the various
Lisps evolved and from whence came Common Lisp.
| 9) Object serilization.
not sure what you mean here.
| 10) Remote method invocation.
this is standard in all network-capable systems, including those written in
Common Lisp. indeed, some Lisp systems work mostly by remotely requesting
a form to be executed, then returning the values.
| 11) Robustness of a static type checker
this is certainly debatable as a feature. Common Lisp compilers typically
offer type inference without needing the programmer to declare all the
types manually. declaring types only helps "prime" the type inference.
| Now, you could do some of these things in lisp, but I refer you to your
| earlier pragmatics model.
I think you're overusing the word "model", and I think your list is highly
debatable as to the already implemented, already done, _factual_ aspects of
Common Lisp that you want to compare to.
| A better list might have showed some examples, and asked how the same
| task might be carried out. If the original list were a valid mothod of
| discussion, I could post some assembler tricks, and smugly ask how it
| would be done in lisp. It would mean nothing related to the current
| discussion, much like the original list.
my guess is you'd be very surprised to learn just how much low-level stuff
can be done in Lisp.
Erik Naggum
* Brian Rogoff
| I don't understand your point. Java has multithreading as part of
| the language standard. See
|
| http://www.javasoft.com/doc/language_specification/17.doc.html
|
| if you don't believe me. This is a fact. Whether or not you like the
| particular choice of multithreading primitives, and whether or not extant
| implementations support it fully, is not what I am arguing. ANSI Common
| Lisp has no primitives for multithreading. That Franz, Harlequin, and
| others may provide multithreaded implementations is also outside the
| scope of my argument, but I certainly don't think I was "grossly unfair".
| The thread packages in Common Lisp implementations are vendor specific.
| Do you dispute this?
I hate it when people are fully aware they don't understand the point and
yet go on imply that I don't believe or dispute simple facts. puh-lease!
the point is simply that both Java and Common Lisp implementations include
multithreading, but because of practical problems in the standard process
for ANSI Common Lisp (i.e., obtaining consensus), it is not included in the
standard. all Common Lisp systems have good debuggers, foreign function
interfaces, editors, inspectors, etc, most of which are at best only hinted
at in the standard. Java is a specification closer to the implementation,
and intentionally so. considering this, it's grossly unfair to compare the
language, and not the implementations.
Cyber Surfer
With a mighty <3343CD...@pcisys.net>,
bmi...@pcisys.net uttered these wise words...
> Jason Trenouth wrote:
> >
> > I still contest that Java is a poor substitute for Common Lisp.
>
> I suspect your complaints are against the java language, and not
> the jvm. Writing a lisp interpreter that targets the jvm has
> already been done more than once. So you can write applets in
> lisp and market them as java code.
Or even a Lisp compiler. Some Lisp compilers produce C source code.
The same is true for a number of Prolog (and Prolog-like) languages.
Perhaps we'll see some Lisp and Prolog compilers that generate Java
source code, and more compilers that create JVM bytecodes directly.
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.
However, this needn't depend on us all using Java. It merely depends
on the quality of the "black box", i.e. the JVM, and that's rapidly
improving. Even if it seems impractical to some of us today, it's easy
to "sell to your management", which should buy us a bit of time.
I'm assuming that it's the JVM that's making Java so successful, and
not something else, like Web applets. That's another issue. ;)
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
Paul Prescod
In article <5i22q2$g...@mulga.cs.mu.OZ.AU>,
Fergus Henderson <f...@mundook.cs.mu.OZ.AU> wrote:
>Even processing things at a that level, term_expansion macros
>share quite a few of the problems of C macros, including
>added tempatation to invent inscrutable new languages that no-one
>else will understand, difficulty of source-level debugging, etc.
Unfortunately in the absence of powerful macros, people invent
languages like "awk", "perl" and C++ -- which are inscrutable,
hard to understand and difficult to source-level debug. I think
that it is better to not invent a new language to support every
new programming paradigm or application domain. Every time we
do, we forget all of the good things from the older languages.
With macros you can make old languages handle new application
domains and paradigms naturally.
Paul Prescod
James F'jord Lynn
In article <30691419...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>I hate it when people are fully aware they don't understand the point and
>yet go on imply that I don't believe or dispute simple facts. puh-lease!
>keyword< in the >Java language<
Multithreading is part of the >Java language<
--
Royalty free widgets - http://www.undergrad.math.uwaterloo.ca/~j2lynn/java.html
David Hanley
Erik Naggum wrote:
>
> * Brian Rogoff
> | Java has multithreading facilities built into the language. While there
> | are certainly Lisps, notably EuLisp, which also have built in threads,
> | ANSI Common Lisp does not. This may be important to some people.
>
> don't you think it's grossly unfair to compare the two infavorably as long
> as there are implementations that support everything you ask for? I do.
'unfair' in what respect?? I thought we were interested in pragmatics
here. ;) If Java does 'X' better talking about the pressure the
implementers were under is not terribly ineresting.
dave
James F'jord Lynn
Marco Antoniotti <mar...@infiniti.PATH.Berkeley.EDU> wrote:
>If there where two major developers of Java instead of one and each of
>them had developed its own flavor of 'native' interface,
Then they would cease to be Java vendors. The JNI is a standard part of
Java the runtime (and has little to do with the language as this thread is
about).
>saying the same for Java. The truth is that, given an implementation
>of Common Lisp, its "connectivity to anything non lisp" (which means
>C) is very wel defined and developed.
Ugh. This is worse than the "every language is touring complete" arguments.
David Hanley
Marco Antoniotti wrote:
> Portability, Deliverability, Availability.
>
> I would say that Common Lisp is as portable as Java.
>
Perhaps in source, and as long as you conform strictly to the
ansi standard. Java's library has portable file, network, graphics, etc
in it.
> Compile time semantics checking
>
> CMUCL is pretty good in that respect too.
But it's not standard lisp.
dave
David Hanley
Erik Naggum wrote:
>
> * David Hanley
> | I don't think so. One has to bear in mind that in diffrent languages,
> | one uses different models. In java, I'm not likely to design my program
> | around features that don't exist.
>
> which is, I believe, _the_ point. the weak Sapir-Worf hypothesis states
> that it is hard to think about that for which you do not have a language.
That's not at all what I'm talking about. The fact that java does not
have feature 'x' is not a terribly big deal unless the design of a
specific program cries out for feature 'x'. If there is another,
equally valid design that uses feature 'y', which is present, it isn't a
problem at all. There are few programs which actually require 'x'.
> (the strong Sapir-Worf hypothesis states that you cannot, but this must be
> wrong, considering that new languages and words are created.)
>
> | > | Yes, you do miss out on macros, but macros have disadvantages as well
> | > | as advantages.
> | >
> | > what an amusing argument.
> |
> | Exactly how is it amusing?
>
> imagine it generalized to other things that have "disadvantages as well as
> advantages", i.e., everything -- somehow, this is an argument in favor of
> _not_ supporting it. as such, it is completely devoid of meaning, it is
> ridiculous on its face.
It is not "ridiculous on its face." Pointer arithmetic in C has some
advantages. Lisp doesn't have pointer arithmetic. Therefore, lisp
sucks. Refute.
[deletia]
> | 1) Portable binaries.
>
> several Common Lisp implementations offer portable byte-code binaries, as
> well.
Interesting, but since the format is not specified in the standard,
each vendor creates their own. This means I'm tied to a specific
vendor, and the machines they've decided to support.
> however, most Lisp
> vendors and users find that execution speed is important enough
Shouldn't be using lisp then.. ;)
> to merit
> native compilation. this is also true of Java, I hear, so we're debating
> implementations.
Nope. JIT compilers work quite well.
>
> | 2) Run-in-the browser models.
>
> Java doesn't run in the browser. JVM byte-code does. JVM is intentionally
> crippled, but Scheme->JVM compilers exist. as an execution target, nothing
> prohibits Common Lisp to compile to it, only nobody has done so.
Thanks. That's still a point for me. Rmember, we're discussing
pragmatics here.
>
> | 3) Secure executable model.
>
> ahem. please see comp.risks and the trade magazines for the precise value
> of "secure" which makes "secure" a feature of Java.
Java has a secure executable model. If there is a badly-implemented
browser somewhere, that does not refute this. The browser will be
fixed.
> | 4) True basic types (efficency consideration).
>
> this is something Common Lisp does not have? the mind boggles.
It matters a lot for numerical work and graphics.
>
> | 5) Built-in graphical user interface model (portable).
>
> granted. remove "built-in", and Common Lisp systems support various GUIs.
> stick with one vendor's choice, and you're as far as you get with Java.
No you won't. First of all, sticking with one vendor is bad. It
drives up prices, and locks you into a certian system. You sacrifice
portability along with a lot of other things.
> | 6) *Very* elegant and powerful threading model.
> all the commercial Common Lisp implementations provide multiprocessing.
> again, stick with one vendor, and you're as far as you get with Java.
Is it good? Is it portable? What if I need to change vendors because
we need another gui? Remember, pragmatics!
>
> | 8) Simple foreign function interface.
>
> again, true for any particular Common Lisp vendor. not standardized
> because of the much wider variety of languages to talk to when the various
> Lisps evolved and from whence came Common Lisp.
Reasons why are not too important. The fact no standard, simple one
exists is.
>
> | 9) Object serilization.
> not sure what you mean here.
Changing object 'a into a stream of bytes.
>
> | 10) Remote method invocation.
> this is standard in all network-capable systems, including those written in
> Common Lisp.
But is it part of the standard language? Can I call a function on
another machine and expect a response?
> | 11) Robustness of a static type checker
>
> this is certainly debatable as a feature.
Sure. So are some of the lisp 'fetures'
> | Now, you could do some of these things in lisp, but I refer you to your
> | earlier pragmatics model.
>
> I think you're overusing the word "model", and I think your list is highly
> debatable as to the already implemented, already done, _factual_ aspects of
> Common Lisp that you want to compare to.
I'm not sure what this means.
>
> | A better list might have showed some examples, and asked how the same
> | task might be carried out. If the original list were a valid mothod of
> | discussion, I could post some assembler tricks, and smugly ask how it
> | would be done in lisp. It would mean nothing related to the current
> | discussion, much like the original list.
>
> my guess is you'd be very surprised to learn just how much low-level stuff
> can be done in Lisp.
Probably not.
dave
Johannes Link
Brian N. Miller wrote:
> I suspect your complaints are against the java language, and not
> the jvm. Writing a lisp interpreter that targets the jvm has
> already been done more than once. So you can write applets in
> lisp and market them as java code.
Johannes Link
--
Abteilung fuer Molekulare Biophysik (0810)
Deutsches Krebsforschungszentrum
Im Neuenheimer Feld 280
D-69120 Heidelberg
da...@news.mhv.net
i've programmed in lisp, i've programmed in java. java is a sweet
language. clean, simple, quick to code, quick to debug, sort of
the pascal of the object world. it's my second favorite language
(out of 60+ that i've written programs in).
the fundamental reason i like lisp over ALL of the others has
NOTHING to do with features. discussing features misses the point.
writing lisp code is like breathing. you just do it. there is almost
NO "friction" between the thought and the implementation. i can mix
nearly machine level primitives (CAR => *ptr+0 and research level
concepts (GeneticallyCombine ...) in the same expression. plus the
program is syntactically (and sometimes semantically) the same as
the data. these two properties of lisp make it a "language" you
use to express ideas rather than a "coding vehicle" which everything
else amounts to. there is no distinction between the thought
and the writing of the thought in lisp. (too ZEN-like a notion, i guess)
but that's just my considered opinion.
now if only i could get paid to write lisp again :-)
t
Erik Naggum
* David Hanley
| Java has a secure executable model. If there is a badly-implemented
| browser somewhere, that does not refute this. The browser will be fixed.
I'm happy for you. good luck with Java, David.
Espen Vestre
jos...@lavielle.com (Rainer Joswig) writes:
> The limitations of the Java virtual machine for supporting Lisp and
> similar languages (Smalltalk, Prolog, ...) makes it hard
> to implement these languages efficiently (this was the last
> thing I have heard on this topic). SUN has built a *Java* virtual
> machine - and not a more universal VM. Sigh.
Could you, or someone else, elaborate on that? It's somewhat
disappointing, I sort of naively hoped that Java was close enough to
lisp to make the Java VM suitable as a lisp platform, and it would
really be interesting to know exactly what parts of lisp that makes
it _that_ different from Java (this thread would really benefit
from a serious contribution on this topic!).
--
regards,
Espen Vestre, Telenor Nextel AS
Marc Wachowitz
Johannes Link (j.l...@dkfz-heidelberg.de) wrote:
> Is such a Lisp to Jvm compiler available (commercially or free)?
See http://www.cygnus.com/~bothner/kawa.html for a Scheme to
JVM compiler (the newest version in 1.4, available directly
from ftp://ftp.cygnus.com/pub/bothner/kawa-1.4.tar.gz - last
time I looked, the WWW page still referred to version 1.2).
There is also a document (doc/scm2java.html in the distribution)
about the problems of compiling Scheme to the JVM and his ideas
for a solution; most of that is also valid for other Lisps.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Marc Wachowitz
Espen Vestre (e...@nextel.no) wrote:
> I sort of naively hoped that Java was close enough to
> lisp to make the Java VM suitable as a lisp platform, and it would
> really be interesting to know exactly what parts of lisp that makes
> it _that_ different from Java
See http://www.cygnus.com/~bothner/scm2java.html for a documentation
of some problems with compiling Scheme for the JVM, and approaches
for a solution. It should be obvious from the description that some
of those tricks work against efficiency, and wouldn't be a problem
for a Lisp to native code compiler. Nevertheless, for some kinds of
applications, the attainable performance may still be sufficient.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Dave Harris
cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) wrote:
> > Jason Trenouth wrote:
> > >
> > > I still contest that Java is a poor substitute for Common Lisp.
> >
> > the jvm. Writing a lisp interpreter that targets the jvm has
> > already been done more than once. So you can write applets in
> > lisp and market them as java code.
>
> The same is true for a number of Prolog (and Prolog-like) languages.
> Perhaps we'll see some Lisp and Prolog compilers that generate Java
> source code, and more compilers that create JVM bytecodes directly.
A Scheme to Java bytecode compiler called Kawa is already available. It
generates proper .class files and .zips. See:
http://www.cygnus.com/~bothner/kawa.html
Of course, Scheme is not CLOS.
> 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!
It's not so much whether it can be done, but whether it can be done
reasonably efficiently. For example, I would think that multimethods would
be quite hard to do efficiently in the JVM.
One would like to think that an inefficient translation would be enough,
and that JVM implementations will be smart enough to figure out what the
code really wants and optimise accordingly. However, given that so many
JVMs are implemented as interpreters or JITs, they can't afford much time
for sophisticated analysis.
Dave Harris, Swansea, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
- I speak only for myself - | And drunk the milk of Paradise."
Marco Antoniotti
In article <E84p9...@undergrad.math.uwaterloo.ca> j2l...@undergrad.math.uwaterloo.ca (James F'jord Lynn) writes:
From: j2l...@undergrad.math.uwaterloo.ca (James F'jord Lynn)
Newsgroups: comp.ai,comp.lang.java.advocacy,comp.lang.lisp
Date: Fri, 4 Apr 1997 19:39:03 GMT
Organization: University of Waterloo
Path: agate!newsfeed.kornet.nm.kr!howland.erols.net!torn!kwon!watserv3.uwaterloo.ca!undergrad.math.uwaterloo.ca!j2lynn
Sender: ne...@undergrad.math.uwaterloo.ca (news spool owner)
References: <3340DF...@netvision.net.il> <5huud5$f...@mulga.cs.mu.OZ.AU> <ddyer-03049...@192.0.2.1> <scf4tdn...@infiniti.PATH.Berkeley.EDU>
Nntp-Posting-Host: noether.math.uwaterloo.ca
Lines: 16
Xref: agate comp.ai:45702 comp.lang.java.advocacy:7774 comp.lang.lisp:26402
Marco Antoniotti <mar...@infiniti.PATH.Berkeley.EDU> wrote:
>If there where two major developers of Java instead of one and each of
>them had developed its own flavor of 'native' interface,
Then they would cease to be Java vendors. The JNI is a standard part of
Java the runtime (and has little to do with the language as this thread is
about).
My argument was not against Java "per se" (I like Java more and more -
Gosling and G. L . Steele seem to get closer and closer to the "right
thing") My argument was an "historical one". The evolution of Common
Lisp has not been "centralized" and the different vendors at the time
did play a (nefarious IMHO) role in influencing what went and what
stayed out of the language. The "foreign function interface" (toward
C) in CL parlance is one of these. Multiprocessing (Threading) was
another and the UI substrate was another again.
>saying the same for Java. The truth is that, given an implementation
>of Common Lisp, its "connectivity to anything non lisp" (which means
>C) is very wel defined and developed.
Ugh. This is worse than the "every language is touring
complete" arguments.
This was not an argument. It was a descriptive statement. I you
choose to do your development in CMUCL, you have a perfectly well
defined FFI. The same if you program in Harlequin CL or Lucid or
Allegro. The problem is that there is no incentive for the vendors to
agree on a common FFI.
Because one of those imperscrutable events in history, Java got
developed in one place with the right people in the same lab and with
no competition from other groups. This is history. It has nothing to
do with the merits of one language over the other. But it was
necessary to point out that CL does not "lack" certain features.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
John Nagle
Espen Vestre <e...@nextel.no> writes:
>jos...@lavielle.com (Rainer Joswig) writes:
>> The limitations of the Java virtual machine for supporting Lisp and
>> similar languages (Smalltalk, Prolog, ...) makes it hard
>> to implement these languages efficiently (this was the last
>> thing I have heard on this topic). SUN has built a *Java* virtual
>> machine - and not a more universal VM. Sigh.
>Could you, or someone else, elaborate on that?
I hear that the SELF group at Stanford is trying to adapt their
underlying system, which is a good just-in-time compiler, to support
Java. You might want to check that out.
John Nagle
Rainer Joswig
> jos...@lavielle.com (Rainer Joswig) writes:
>
> > The limitations of the Java virtual machine for supporting Lisp and
> > similar languages (Smalltalk, Prolog, ...) makes it hard
> > to implement these languages efficiently (this was the last
> > thing I have heard on this topic). SUN has built a *Java* virtual
> > machine - and not a more universal VM. Sigh.
>
> Could you, or someone else, elaborate on that? It's somewhat
> disappointing, I sort of naively hoped that Java was close enough to
> lisp to make the Java VM suitable as a lisp platform, and it would
> really be interesting to know exactly what parts of lisp that makes
> it _that_ different from Java (this thread would really benefit
> from a serious contribution on this topic!).
>
> --
>
> regards,
> Espen Vestre, Telenor Nextel AS
See the talk by Olin Shivers at "Dynamic Objects Workshop", May 5-9, 1996,
Boston: "Supporting Dynamic Languages on the Java Virtual Machine".
- the JVM is designed for a monomorphic, statically-typed object-oriented
language
-> one may need boxing and unboxing of small objects
-> performance penalty
- the instruction set of the JVM is tuned to the demands of the Java language
-> example: method lookup is built into the JVM
-> different types of method lookup users (Dylan, CLOS, ...) would not be
able to use the built-in version
See also the discussion at http://wilson.ai.mit.edu/java-vm.html .
MENARD Steve
Espen Vestre (e...@nextel.no) wrote:
: jos...@lavielle.com (Rainer Joswig) writes:
:
: > The limitations of the Java virtual machine for supporting Lisp and
: > similar languages (Smalltalk, Prolog, ...) makes it hard
: > to implement these languages efficiently (this was the last
: > thing I have heard on this topic). SUN has built a *Java* virtual
: > machine - and not a more universal VM. Sigh.
:
: Could you, or someone else, elaborate on that? It's somewhat
: disappointing, I sort of naively hoped that Java was close enough to
: lisp to make the Java VM suitable as a lisp platform, and it would
: really be interesting to know exactly what parts of lisp that makes
: it _that_ different from Java (this thread would really benefit
: from a serious contribution on this topic!).
Well, I'm not an expert at writing compilers, but 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.
First, the lack of pointer to basic types. Since, at any moment, any
data can be put in a list or vector, you must always be able to reference
any data. So, to use simple types (like int, char, double, etc), you must
wrap them in a class. Simple enough to do, however, the overhead of
getting the data from within the wrapper object, and allocating an object
for even simple arithmetics like +, is quite annoying.
Second, there is no instruction, in the JVM, to jump to an arbitrary,
unknown at compile-time location. You can't read an address within a
variable and jump there. So, you can either make each lambda (scheme
procedures) in its own java method, which means you can't to
tail-call optimisation, or you end up creating a dispatch-table(which is
what I did) and "hosting" all the scheme procedures within a single Java
method. Quite easy, until you try to implement "load" ...
Lastly, although the JVM is a stack machine, the local stack handling is
very primitives. Most stack machines I've seen have ways to read cells
other than the top, which does not hold true with the JVM.
I can honestly say that my implementation is quite efficient. It is,
with JIT, about 7-9 times slower than natively compiled cod (which is
about eleven times faster than Kawa, the only other Scheme-on-JVM I know).
However, is is about two times slower than an equivalent java program,
which do not need to encapsulate primitives in objects. BTW, the test
program was Fibonacci(24).
Ther are many such modifications which would be needed in order to be
able to build efficient compiler for other languages. Those features need
not even be used by Java The Language, such as pointers to primitives, but
they should be there if the JVM is to become as ubiquitous as some would
like it to be.
--
----------------------------------------------------------------------------
--- |\_/| Still The One and Only Wolfbane! ---
--- |o o| " Hey! Why ya lookin' at me so weird? Ain't ya 'ver seen a ---
--- \ / decker witha horn ?" --- Scy, Troll decker with a CC ---
--- 0 Steve Menard men...@Jsp.UMontreal.Ca ---
----------------------------------------------------------------------------
Brian Rogoff
On 4 Apr 1997, Erik Naggum wrote:
> I hate it when people are fully aware they don't understand the point and
> yet go on imply that I don't believe or dispute simple facts. puh-lease!
And I hate it when people take a very clear statement of a fact, that the
Java language has multithreading as part of the standard, and that ANSI
Common Lisp does not, and then insinuate that the person stating these
facts is being grossly unfair.
> the point is simply that both Java and Common Lisp implementations include
> multithreading, but because of practical problems in the standard process
> for ANSI Common Lisp (i.e., obtaining consensus), it is not included in the
> standard.
And my point, which at least two other people seemed to get effortlessly,
is that threads are part of the Java standard, and that I can write source
code using threads in Java, and that source code should work with the
compiler that any vendor provides, provided I stay within the standard. I
am not concerned here with *why* the Common Lisp standard doesn't discuss
concurrency, only that it doesn't, and that you can't count on it being
there.
Many Scheme implementations now include module systems, threads,
exceptions, and object systems, even though none of these are in R4RS.
Hence I wouldn't claim that a comparison between Common Lisp and Scheme
which stated that Common Lisp has an object system, CLOS, and that Scheme
does not, is grossly unfair, provided that it is clear that ANSI and R4RS
standards are being discussed.
> all Common Lisp systems have good debuggers, foreign function
> interfaces, editors, inspectors, etc, most of which are at best only hinted
> at in the standard. Java is a specification closer to the implementation,
> and intentionally so.
Really, you've used all of them, and all of the free Common Lisp systems
have all of these extra-lingual tools?
> considering this, it's grossly unfair to compare the
> language, and not the implementations.
You should consider a career as a lawyer.
-- Brian
Marco Antoniotti
In article <334578...@nospan.netright.com> David Hanley <da...@nospan.netright.com> writes:
From: David Hanley <da...@nospan.netright.com>
Newsgroups: comp.ai,comp.lang.java.advocacy,comp.lang.lisp
Date: Fri, 04 Apr 1997 15:52:59 -0600
Organization: netright Technologies
Reply-To: da...@nospam.netright.com
Path: agate!news.ucdavis.edu!news.wwa.com!gail.ripco.com!newsgate.nytimes.com!newsfeeds.sol.net!worldnet.att.net!howland.erols.net!psinntp!pubxfer1.news.psi.net!usenet
Lines: 18
References: <3340DF...@netvision.net.il>
<3341B6...@felix.cc.gatech.edu> <nagleE7...@netcom.com>
<3365440d.698147468@newshost> <5huud5$f...@mulga.cs.mu.OZ.AU>
<ddyer-03049...@192.0.2.1> <scf4tdn...@infiniti.PATH.Berkeley.EDU>
NNTP-Posting-Host: 38.232.49.2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (WinNT; I)
Xref: agate comp.ai:45749 comp.lang.java.advocacy:7824 comp.lang.lisp:26448
Marco Antoniotti wrote:
> Portability, Deliverability, Availability.
>
> I would say that Common Lisp is as portable as Java.
>
Perhaps in source, and as long as you conform strictly to the
ansi standard. Java's library has portable file, network, graphics, etc
in it.
Granted.
> Compile time semantics checking
>
> CMUCL is pretty good in that respect too.
But it's not standard lisp.
It was last time I checked. Where "standard" means "as close as you
can get to ANSI CL".
David Thornley
In article <334578...@nospan.netright.com>,
David Hanley <da...@nospam.netright.com> wrote:
>Marco Antoniotti wrote:
>
>> Portability, Deliverability, Availability.
>>
>> I would say that Common Lisp is as portable as Java.
>>
>
> Perhaps in source, and as long as you conform strictly to the
>ansi standard. Java's library has portable file, network, graphics, etc
>in it.
>
reasonable form of Common Lisp runs on and Java doesn't, such as
Windows 3.1 systems.
Java has *potential* portability advantages, having been standardized
before it became popular. Whether this results in real portability
remains to be seen. Both Ada and Pascal went on this path. Ada is
generally portable, while Pascal isn't. Sun has a vested interest
in keeping Java portable, while Microsoft has a vested interest in
pushing Windows 95 extensions as vital.
Java does indeed specify some things in its standard that Common Lisp
doesn't, and the reverse is true also. Since the Java standard was
created, while Common Lisp evolved, I'd bet that there's a lot more
gotchas in the Java standard. It is possible that some of them will
turn out to be serious enough that implementors go to implementation-
specific solutions, and this can hurt portability.
In other words, praising Java for portability is making predictions
which may or may not be true, since currently it is less source-code
portable than Common Lisp. If we were to compare the languages
pragmatically, based on current implementations, we'd find that
Java IDEs generally suck, there's major problems with 1.0.2 AWT,
and so forth.
It's also worth considering the tradeoffs. Java has specified an
execution model in considerable detail, in an effort to gain portability.
This has two major tradeoffs. First, it complicates implementation.
You can't implement Java on a system without coming up with some sort
of graphics and threading ability. This, to some extent, inhibits
portability, as there are fewer systems that can run it at all. Second,
it can be a big performance hit. If, for some reason, the JVM is not
a good fit on a system, it will run very slowly. Even if it is a fairly
good fit, it will often be interpreted, and even a just-in-time compiler
will probably not bring it up to the speed of a good Common Lisp compiler.
One large difference is that CL, more than most languages, hides the
machine-level semantics. The compiler is free to take the program as
the intent of the programmer, and use whatever system-specific
shortcuts are available to produce efficient code. Java byte code
specifies machine-level semantics in great detail, and so the emulator
will generally have to do a lot of extra work.
It is possible to write compilers from Java directly into native code,
but the resulting programs will be no more portable than Lisp
compilations. Further, these are sure to accrete limitations and
extensions that will make source-code porting more difficult.
In theory, examining the specifications, Java is more portable than
Common Lisp, and nothing in the specifications explicitly forbids
Java to be as efficient. In practice, Java suffers a big performance
hit. Further, Java may not wind up being as portable as hoped for.
Once Java is available on as many sorts of systems as Common Lisp is,
we can start making more fair comparisons.
David Thornley
David Hanley
Erik Naggum wrote:
>
> * David Hanley
> | browser somewhere, that does not refute this. The browser will be fixed.
>
So, if you found a broken lisp implementation somewhere, you would stop
using lisp completely?
As for 'good luck with java' I am using java on my current project
becuase it is the 'best fit'. As I move on to new projects, I will
evaluate the 'best fit' for that project, based on the specs, and the
tools available. Who knows, I might program a large lisp app one day..
If it's the best choice; say, if I'm doing a lot of symbolic
computation.. Who knows?
dave
Brian Rogoff
On 4 Apr 1997, Fergus Henderson wrote:
> Bruce Tobin wrote:
> > I suspect you're thinking of C macros, which are a whole different (and
> > vastly inferior) animal. Lisp macros are far more flexible and
> > powerful, and permit techniques which solve most of the problems
> > associated with simple string-replacement macros.
>
> I know that lisp macros work on s-expressions, not on strings.
> (Hey, even C macros work on tokens, not strings...)
>
> I'm not very familiar with lisp macros, but I imagine that they are
> probably pretty similar to something that I am quite familiar with,
> namely Prolog's de facto standard `term_expansion' feature, which is
> preprocessing at the level of Prolog terms.
I think that this illustrates one problem of looking at a particular
feature of a language, in this case Lisp macros, in isolation. While I
agree with Fergus that macros have disadvantages, the simple syntax of
Lisp ameliorates many of these difficulties, and makes it quite easy to
invent new languages atop Lisp which look quite Lispy, like CLOS. While
I don't consider myself a Lisp expert yet, I've certainly become more
comfortable with macros as I've used Lisp more. Certainly they require
great care, and without strict guidelines they can lead to a great mess,
but in the hands of a knowledgeable programmer they are amazingly powerful.
-- Brian
David Hanley
MENARD Steve wrote:
>
> Espen Vestre (e...@nextel.no) wrote:
> : jos...@lavielle.com (Rainer Joswig) writes:
> :
> : > The limitations of the Java virtual machine for supporting Lisp and
> : > similar languages (Smalltalk, Prolog, ...) makes it hard
> : > to implement these languages efficiently (this was the last
> : > thing I have heard on this topic). SUN has built a *Java* virtual
> : > machine - and not a more universal VM. Sigh.
> :
> : Could you, or someone else, elaborate on that? It's somewhat
> : disappointing, I sort of naively hoped that Java was close enough to
> : lisp to make the Java VM suitable as a lisp platform, and it would
> : really be interesting to know exactly what parts of lisp that makes
> : it _that_ different from Java (this thread would really benefit
> : from a serious contribution on this topic!).
> :
> Well, I'm not an expert at writing compilers, but 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.
>
> First, the lack of pointer to basic types. Since, at any moment, any
> data can be put in a list or vector, you must always be able to reference
> any data. So, to use simple types (like int, char, double, etc), you must
> wrap them in a class. Simple enough to do, however, the overhead of
> getting the data from within the wrapper object, and allocating an object
> for even simple arithmetics like +, is quite annoying.
I'm working on a ml->bytecode compiler. Now, in ml, you can determine
that
a list( or a container ) is all of one type at compile time, and
directly manipulate basic types, so this overhead isn't there. I know
that in scheme, you can do quite a bit of type inference in most
programs; this might help your speed a lot.
>
> Second, there is no instruction, in the JVM, to jump to an arbitrary,
> unknown at compile-time location. You can't read an address within a
> variable and jump there. So, you can either make each lambda (scheme
> procedures) in its own java method, which means you can't to
> tail-call optimisation, or you end up creating a dispatch-table(which is
> what I did) and "hosting" all the scheme procedures within a single Java
> method. Quite easy, until you try to implement "load" ...
I'm not quite clear what you're getting at, but My scheme is to define
virtual base classes for all the call signatures, derive a method-object
from that base class, and allocate an instance when we try to get a
pointer to that method. This seems to be pretty efficent, and works for
currying, as well.
> Lastly, although the JVM is a stack machine, the local stack handling is
> very primitives. Most stack machines I've seen have ways to read cells
> other than the top, which does not hold true with the JVM.
True, but java is not a pure stack machine; you can have local
variables,
which you can always get at. But, you are further along that I, so you
may have discovered more problems.. ;)
>
> Ther are many such modifications which would be needed in order to be
> able to build efficient compiler for other languages. Those features need
> not even be used by Java The Language, such as pointers to primitives, but
> they should be there if the JVM is to become as ubiquitous as some would
> like it to be.
>
That, I agree with. Though, I think that with some strong
optimizations, you could compiler functional code->JVM with similar
speed to natively compiled code. Does gambit do type inference? Were
you able to use this?
dave
David Hanley
David Thornley wrote:
>
> In article <334578...@nospan.netright.com>,
> David Hanley <da...@nospam.netright.com> wrote:
>
> > Perhaps in source, and as long as you conform strictly to the
> >ansi standard. Java's library has portable file, network, graphics, etc
> >in it.
> >
> Where Java exists. There are still quite a few machines that some
> reasonable form of Common Lisp runs on and Java doesn't, such as
> Windows 3.1 systems.
There are at least 2 java implementations for windows 3.1.
>
> Java has *potential* portability advantages, having been standardized
> before it became popular. Whether this results in real portability
> remains to be seen.
The application I am writing works on at least 7 different platforms as
it currently stands. You may ot may not consider this true portability,
but I sure do.
> Java does indeed specify some things in its standard that Common Lisp
> doesn't, and the reverse is true also. Since the Java standard was
> created, while Common Lisp evolved, I'd bet that there's a lot more
> gotchas in the Java standard.
Okay--can you point some out? While you're at it, can you explain why
evolution would lead to fewer gottcha's than design?
> In other words, praising Java for portability is making predictions
> which may or may not be true, since currently it is less source-code
> portable than Common Lisp.
Sorry, I'm not buying this for 1/2 second. As follows:
import java.awt.*;
class Test extends Frame
{
Test()
{
setLayout( new FlowLayout() );
add( new Button( "Ok" ) );
show();
resize( 250 , 150 );
}
public static void main( String [] args )
{
}
}
This is going to run, without change on windows NT, 95, 3.1,
AIX, SUN, Os/2, HP/UX, Macintosh, SGI, VMS, BSD, and a couple of others
I'm probably forgetting. Even if I had used threads. Please show me a
lisp program as portable, even as source.
> If we were to compare the languages
> pragmatically, based on current implementations, we'd find that
> Java IDEs generally suck,
Gee, I like symnatec cafe pretty well.
>
> It's also worth considering the tradeoffs. Java has specified an
> execution model in considerable detail, in an effort to gain portability.
> This has two major tradeoffs.
You say tradeoff, but you don't bother to examine what it gains by
these tradeoffs. Bad argumentation.
> First, it complicates implementation.
> You can't implement Java on a system without coming up with some sort
> of graphics and threading ability. This, to some extent, inhibits
> portability, as there are fewer systems that can run it at all.
How absurd. The fact that the implementor has to conform to the
standard means that once the VM is implemented, the software will be
portable. The alternative would be to not specify these details, and
create vast amounts of unportable software.
Also, what are these systems we are writing software for which do not
have graphics, nor any mechanism for simulating threads? Incidentally,
do they have enough memory to run common lisp?
> Second,
> it can be a big performance hit. If, for some reason, the JVM is not
> a good fit on a system, it will run very slowly.
Could you give an example of such a system, and show how another
language would run more quickly, like, say, lisp?
> Even if it is a fairly
> good fit, it will often be interpreted,
Not true on any newer system/
> and even a just-in-time compiler
> will probably not bring it up to the speed of a good Common Lisp compiler.
Completely untrue. If it it not already faster( it probably is for a
lot of applications ) java will certianly be faster after the VM's get
shaken out.
> One large difference is that CL, more than most languages, hides the
> machine-level semantics. The compiler is free to take the program as
> the intent of the programmer, and use whatever system-specific
> shortcuts are available to produce efficient code.
So, based on your argument, Lisp should be very fast, C should be
slugish, and assembler should be dog-slow. I may be going out on a limb
here, but this is not verified by my real-life experience.
Particularly for small functions, lower-lever languages will almost
always win. Sometimes in large programs, higher level languages will
win ( be faster ) because the abstrctions help us focus on our
algorithms.
> Java byte code
> specifies machine-level semantics in great detail, and so the emulator
> will generally have to do a lot of extra work.
I get the sneaking suspicion you don't know the bytecode all that
well. The bytecodes are both simple and high-level, allowing a lot of
optimizations. They're not perfect, but they're not too bad, either.
Could you perhaps show and example of where lisp could be more highly
optimized than idiomatic java? ( The last 2 words there rule out tail
reusrions as an example. )
> Once Java is available on as many sorts of systems as Common Lisp is,
> we can start making more fair comparisons.
One thing we could do is compare the portability of java on the
available platforms, with some real programs. Are you game?
>
> David Thornley
david hanley
Mark 'Kamikaze' Hughes
David Thornley <thor...@visi.com> spake:
>Where Java exists. There are still quite a few machines that some
>reasonable form of Common Lisp runs on and Java doesn't, such as
>Windows 3.1 systems.
http://ncc.hursley.ibm.com/javainfo/hurindex.html
Try another example.
>If we were to compare the languages
>pragmatically, based on current implementations, we'd find that
>Java IDEs generally suck, there's major problems with 1.0.2 AWT,
>and so forth.
As opposed to the incredibly powerful and universally portable IDEs and GUI
libraries included as part of Common Lisp.
-- <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
David Thornley
In article <slrn5kiilh....@turbonet.com>,
Mark 'Kamikaze' Hughes <kami...@kuoi.asui.uidaho.edu> wrote:
>David Thornley <thor...@visi.com> spake:
>>Where Java exists. There are still quite a few machines that some
>>reasonable form of Common Lisp runs on and Java doesn't, such as
>>Windows 3.1 systems.
>
>http://ncc.hursley.ibm.com/javainfo/hurindex.html
>
> Try another example.
>
job there of being a free Common Lisp. Has Java been ported to
everything CMU-CL has been ported to? I suspect that you'll find
platforms with Gnu Common Lisp and no Java for a long time.
In other words, Common Lisp source code is more portable than
Java source or byte code. I expect this to be true for a long time
to come.
>>If we were to compare the languages
>>pragmatically, based on current implementations, we'd find that
>>Java IDEs generally suck, there's major problems with 1.0.2 AWT,
>>and so forth.
>
> As opposed to the incredibly powerful and universally portable IDEs and GUI
>libraries included as part of Common Lisp.
>
Powerful, yes. Portable, well, that depends. CLIM is commercial but
runs on Windows and Unix. Garnet is free, if unsupported, and runs on
Mac and Unix. IDEs vary.
Look, I'm not knocking Java, just the hype associated with it.
Java, right now, is of limited portability. This is likely to change,
but porting the JVM to some environments seems to be difficult.
Further, this portability comes with some massive costs in performance,
and possibly reliability. This isn't part of the standard, but it's
true nonetheless.
Java is currently a very uniform language (if you'll disregard the
fact that Java 1.1 is not available on many platforms). This is
because it was standardized before it was widely implemented.
This comes with risks: if the language is found to be deficient
in some areas, as Pascal was, the uniformity will be blown as every
implementor defines their own extensions. Part of the design process
seems to me to be the removal of all C++ features the design team
didn't consider worth keeping, and this is dangerous to do. This is
the Pascal/Ada approach, as opposed to the C/Fortran/COBOL approach
of widespread implementation and experimentation driving the standard.
It looks to me that Java was well done, but it's still very new, and
can have hidden gotchas (or not-so-hidden gotchas that have been
covered up with hype or promises).
Realistic comparisons have to be based on comparable things. You've
been comparing apples and unicorns. You've been comparing how Lisp
is with how Java might be. It could turn out that all the graphics
problems will be fixed very nicely. The IDEs will become better.
All major platforms may start supporting the JVM (remember, though,
that the demands it makes ensure that it won't be as portable as
Common Lisp or C source code). It could well be that the designers
put everything useful into Java, and there will be little temptation
(except for Microsoft) to put system-specific extensions in. It
could even happen that this is done without the major compromises that
usually go along with widespread implementation. You're assuming
that all of this will happen, which seems to me a major leap of faith.
After all, the free CLIM project could put a good, standard GUI on
all Lisps capable of supporting one. There are superb Lisp IDEs
(and no more varied from one another than the Java IDEs: Cafe, J++,
Roaster, Metrowerks, etc.). Competition could drive Lisp system
prices down. In other words, everything you've suggested that is
inferior about Common Lisp could go away. (I except object-code
portability, since that's of dubious value and quite expensive.)
I don't know which of these scenarios is more likely, frankly. I'd
like to see both of them happen. Assuming one of them and not the
other seems to me either foolish or dishonest. The fact is that,
right now, Common Lisp is a better overall language than Java, and
Java is improving faster. The potential for either language is great.
Personally, I think Common Lisp will outlast Java, but I wouldn't
put serious money on it.
David Thornley
Eric M. Kidd
jos...@lavielle.com (Rainer Joswig) writes:
> SUN has built a *Java* virtual machine - and not a more universal VM.
Espen Vestre <e...@nextel.no> wrote:
> Could you, or someone else, elaborate on that? It's somewhat
> disappointing, I sort of naively hoped that Java was close enough to
> lisp to make the Java VM suitable as a lisp platform, and it would
> really be interesting to know exactly what parts of lisp that makes
> it _that_ different from Java (this thread would really benefit
> from a serious contribution on this topic!).
Hmmm. In a nutshell: Making LISP run quickly usually requires a number of
interesting tricks. The JVM security model doesn't allow most of those
tricks. Some of the workarounds are difficult and slow.
LISP programs frequently mix integers and objects. A cons cell, for
example, can hold two pieces of data of any type. This means that a
LISP->JVM compiler must either use the inefficient integer objects, or
somehow calculate when it is safe to use primitive integers. A native LISP
implementation would normally use tagged pointers or some other clever way
of efficiently representing primitive data as objects.
Many LISP compilers perform tail-call optimization. When the last statement
in a function is a call to another function, it's possible to rearrange the
stack and just jump to the second function using a branch instruction. LISP
compiler authors tell me that this is often a profitable optimization. (JVM
security policies might even interfere with some tail-*recursion*
implementations, and that would be truly catastrophic. I still need to
check this.)
Multiple dispatch and multiple inheritance do *not* get along with the JVM.
Most LISP compilers use very complex and sophisticated implementations of
these features. Realistically, they should be built into the VM for
adequate performance.
JVM security is pretty clever, but gets in the way of fully optimizing
LISP, Scheme and Dylan. This isn't to say that it can't be done; this
thread has already mentioned two Scheme->JVM compilers. Now if only I can
figure out how to compile Dylan into Scheme... *wicked grin*
Cheers,
Eric
Anthony Lander
>The limitations of the Java virtual machine for supporting Lisp and
>similar languages (Smalltalk, Prolog, ...) makes it hard
>to implement these languages efficiently (this was the last
>thing I have heard on this topic). SUN has built a *Java* virtual
>machine - and not a more universal VM. Sigh.
As an interesting side note, a guy at ParcPlace has developed a cross-compiler
called Frost which compiles Java onto the VisualWorks Smalltalk VM. The
resulting code runs more than twice as fast as the Sun VM.
The obvious argument - that the VisualWorks VM has been under refinement for
the last 15 to 20 years - clearly holds. It is also worth noting that because
the Smalltalk VM and bytecodes are more general (e.g. everything is an
object), it is possible to make significant global optimizations.
-Anthony Lander
The Object People
--------
100% Pure . . .
James F'jord Lynn
Marco Antoniotti <mar...@porsche.PATH.Berkeley.EDU> wrote:
>In article j2l...@undergrad.math.uwaterloo.ca (James F'jord Lynn) writes:
>My argument was not against Java "per se" (I like Java more and more -
>Gosling and G. L . Steele seem to get closer and closer to the "right
>thing") My argument was an "historical one". The evolution of Common
>Lisp has not been "centralized" and the different vendors at the time
>did play a (nefarious IMHO) role in influencing what went and what
>stayed out of the language. The "foreign function interface" (toward
>C) in CL parlance is one of these. Multiprocessing (Threading) was
>another and the UI substrate was another again.
But is this a good thing or a bad thing. The above just makes me happier
that Java was not this way and dread the day it is.
> >saying the same for Java. The truth is that, given an implementation
> >of Common Lisp, its "connectivity to anything non lisp" (which means
> >C) is very wel defined and developed.
>
> Ugh. This is worse than the "every language is touring
> complete" arguments.
>
>This was not an argument. It was a descriptive statement.
So is saying "every language is turing complete".
>Because one of those imperscrutable events in history, Java got
>developed in one place with the right people in the same lab and with
>no competition from other groups. This is history. It has nothing to
>do with the merits of one language over the other. But it was
>necessary to point out that CL does not "lack" certain features.
But it is also necessary to point out that it does lack certain
>standardized< features that are found in Java just as Java lacks certain
standardized features that are in CL. This does not mean they can not be done
and it does not mean that an API can exist to provide them. It just means that
they aren't standard.
As far as this whole thread goes, it seems rather ludacrous to me to compare
the two languages. "Java's no replacement for common lisp!" Well the Sun's
no replacement for water, but that doesn't mean jack or shit when the lights
go out.
The point is that LISP (original LISP now) was designed for one thing:
AI. Because of this, it allows some constructs that are not typically needed
in non-AI projects. Oak was designed for embedded systems, and Java
add some more design issues giving what we have: robustness, multithreading,
network friendliness, abstraction and object-orientism, security smurfing,
internationalization, dynamism, and simplicty. 1.1 added more network
friendliness, more dynamisism, database awareness, component structuring,
encryption, and data awareness. What the hell am I talking about? well..
Robustness: bounds checking on arrays, dereference checks, dynamic cast checks
all add to the robustness of a system. I know a lot of times it's just a
pain in the ass to handle, but it's better than not being able to handle it
at all.
Multithreading: the syncronized keyword adds a powerful multithreading
primative. The Object class has key monitor related methods and the API
makes multithreading simple to achieve.
Network Friendliness (mix of 1.0/1.1): The net API is standardized, object
serialization allows for exciting network useds, all build ontop of a
platform neutral system that works well in homogenous network environments.
Top this off with RMI abstraction, badda bing, badda bang, cold fusion.
Abstraction and object-orientism: Abstraction through interfaces, OO through
inheritance. It is a new model that takes getting used to, but it can
actually work wonders for design.
Security smurfing: The Java runtime allows you to define any security smurf
you may wish to impose on your system or subsets of your system. One
section of your application may have a different security smurf applied to it
than another and the smurf may change based on whatever the hell you feel
like. Sections are defined by classloader instance and it is trival to
implement smurfs that would have previously taken kernel hacking. All of
this is standardized. The bytecode verifier helps a little here too.
I8n: Unicode, yadda yadda. At least they tried (can you tell I'm not a big
Unicode fan).
Dynamicism (1.0/1.1 mix): Dynamic linking, custom classloaders (linkers),
dynamic method invocation through reflection (yeah yeah this is in lisp.
the custom class loaders aren't tho)
Database awareness: Formal interface defined to databases through JDBC and
SQL
Component structuring: Java Beans gives a standardized structured way of
defining a component and there is the API to support it.
Encryption: standard interfaces for encryption concepts (public-private keys,
blah blah) and BigNum classes for doing quick RSA rip-offs in less than
a second.
Data awareness: standardised "Universal Data Transfer Mechanism", with
model and supporting API
Java also tends to have more infrastructure and CL has, i.e. there are more
people running Netscape, IE, and HotJava, than are running a CL interpreter
and deployment is handled for you.
Java also tends to look more like C++ than CL, and so it is an easier
transition. The standardized API's give C++'ers a reason to stay.
But the thing is that CL has advantages over Java. And in the applications
where those advantages are key, then don't use Java. Use that Scheme thingy
that those people with those hands did. Or write a CL->Java converter and
use CL. Or just use CL.
But I advocate Java for doing serious application work. I don't currently
advocate it for fluffy Windows App type application work, but for serious
apps, I think it is more than ready. It's also good for non-action games. I
would say great for MOOs, but I can also see CL being better at those in
certain cases.
Beyond that, I don't know, cause I don't go there.
Jason Trenouth
On Thu, 03 Apr 1997 18:25:05 -0600, Rob Mayoff <may...@tkg.com> wrote:
> Jason Trenouth wrote:
>
> > The language. I believe (correct me if I'm mistaken) that in Java, the stack
> > is unwound _before_ a handler runs. This makes some kinds of recovery much
> > clumsier than in Common Lisp, where the handler can run with all the context
> > of the signaller.
>
> Yes, for exception handlers Java has termination semantics, not
> resumption semantics. See "The Design and Evolution of C++" (by Bjarne
> Stroustrup), section 16.6. He discusses at length why they choose
> termination semantics for C++ (and the reasons given include significant
> real-world experience with both kinds of semantics). All the same
> arguments apply for Java.
Since I don't have a copy of that book, could you post a brief summary of the
points he makes?
BTW Here is what the DRM [1] has to say (p104):
"Exiting exception systems are acceptable for errors. However, they do not
work for an exception that is not an error and doesn't require an exit, either
because there is a default way to handle it and recover or because it can be
safely ignored by applications that don't care about it. Non-error exceptions
are quite common in networked environments, in computers with gradually
expiring recources (such as batteries), in complex user interfaces, and as one
approach for reflecting hardware exceptions such as page protection violations
or floating-point overflow to the application."
> > > I don't know what you mean by "no real dynamism".
> >
> > In this case I meant sometimes having to explicitly tell the compiler what the
> > type is (via a cast) in order get something to work (again, correct me if I'm
> > misinformed). In languages like Common Lisp and Dylan, adding explicit typing
> > doesn't change the semantics of the program: it only improves its performance
> > or error checking.
>
> The fact that you have to sometimes specify a cast isn't (IMHO) a
> reduction of dynamism, and it allows static type-checking. You still
> get dynamic binding, which is "real dynamism".
I think that we'll have to agree to differ on that point.
__Jason
[1] Dylan Reference Manual, Addison Wesley Publishing Company Inc, 1996.
Anthony Lander
In article <5igmae$3lu$2...@newsfeed.ftn.net>, ant...@objectPeople.com (Anthony Lander) wrote:
>
>As an interesting side note, a guy at ParcPlace has developed a cross-compiler
>called Frost which compiles Java onto the VisualWorks Smalltalk VM. The
>resulting code runs more than twice as fast as the Sun VM.
Sorry - I checked my references only to find out that I've made a small error.
Frost is twice as fast as the fastest Java VMs -- it's *twenty times
faster* than the Sun VM.
-Anthony Lander
John Nagle
Rob Mayoff <may...@tkg.com> writes:
>Jason Trenouth wrote:
>> The language. I believe (correct me if I'm mistaken) that in Java, the stack
>> is unwound _before_ a handler runs. This makes some kinds of recovery much
>> clumsier than in Common Lisp, where the handler can run with all the context
>> of the signaller.
>Yes, for exception handlers Java has termination semantics, not
>resumption semantics. See "The Design and Evolution of C++" (by Bjarne
>Stroustrup), section 16.6. He discusses at length why they choose
>termination semantics for C++ (and the reasons given include significant
>real-world experience with both kinds of semantics). All the same
>arguments apply for Java.
LISP has much cleaner break semantics than C++, and especially
Java, so it is possible to do recovery. But except for debugging,
it's probably not a good idea.
At the other extreme, there's Ada. Ada introduced exceptions
with termination semantics, and Ada needs to work that way; it
supports exceptions for hardware errors, like memory parity.
Ada is used for embedded applications like aircraft control systems,
where recovery is essential.
John Nagle
Nils Nieuwejaar
David Thornley <thor...@visi.com> wrote:
>Where Java exists. There are still quite a few machines that some
>reasonable form of Common Lisp runs on and Java doesn't, such as
>Windows 3.1 systems.
Microsoft, IBM, and Netscape all have JVMs for Windows 3.1.
David Thornley
In article <334983...@nospan.netright.com>,
David Hanley <da...@nospam.netright.com> wrote:
>David Thornley wrote:
>>
>> In article <334578...@nospan.netright.com>,
>> David Hanley <da...@nospam.netright.com> wrote:
>>
>> > Perhaps in source, and as long as you conform strictly to the
>> >ansi standard. Java's library has portable file, network, graphics, etc
>> >in it.
>> >
>> Where Java exists. There are still quite a few machines that some
>> reasonable form of Common Lisp runs on and Java doesn't, such as
>> Windows 3.1 systems.
>
> There are at least 2 java implementations for windows 3.1.
>
you referring to beta implementations? I always like to see actual
releases before making claims. This is what I dislike about Java
hype: it's founded on promises and betas.)
>>
>> Java has *potential* portability advantages, having been standardized
>> before it became popular. Whether this results in real portability
>> remains to be seen.
>
> The application I am writing works on at least 7 different platforms as
>it currently stands. You may ot may not consider this true portability,
>but I sure do.
>
>> Java does indeed specify some things in its standard that Common Lisp
>> doesn't, and the reverse is true also. Since the Java standard was
>> created, while Common Lisp evolved, I'd bet that there's a lot more
>> gotchas in the Java standard.
>
> Okay--can you point some out? While you're at it, can you explain why
>evolution would lead to fewer gottcha's than design?
No, and that's the point. People have been using and abusing Lisp for
decades now. We haven't been doing the same for Java. We haven't
stress-tested the language. It is very possible that Java will
prove very awkward for some applications that are currently being
avoided. (No, I don't know what these will be.)
I'm going by the historical record here. The languages that have
lasted, the ones with histories, are the ones that have evolved.
COBOL, Fortran, Lisp, C, Basic. The languages that have been
standardized from the start, such as PL/1 and Pascal, have generally
not been nearly as successful. Java and Ada are the two current
success stories of the design process, with Pascal some distance
behind.
In other words, I don't know what Java will be like ten years down
the road. It's likely to be around in some form, but what?
>> In other words, praising Java for portability is making predictions
>> which may or may not be true, since currently it is less source-code
>> portable than Common Lisp.
>
> Sorry, I'm not buying this for 1/2 second. As follows:
>[button implementation omitted]
>
> This is going to run, without change on windows NT, 95, 3.1,
>AIX, SUN, Os/2, HP/UX, Macintosh, SGI, VMS, BSD, and a couple of others
>I'm probably forgetting. Even if I had used threads. Please show me a
>lisp program as portable, even as source.
>
Ummm,
(defun fact (x)
(if (< x 2)
x
(* n (fact (1- x)))))
should run on lots more machines than that (assuming I've got it
right, typing it into a non-Lisp-aware editor).
Oh, you were expecting a graphics program? Sorry, those aren't
nearly as portable. Further, it still isn't clear to me that they
should be. The Macintosh, X-Windows, Windows 95, and others are
noticeably different systems, and any true multi-platform graphics
system is going to have to accomodate the lowest common denominator.
This is a tradeoff.
(BTW, CLIM is generally available on Unix and Windows Lisps, at added
cost. If it were ported to the Mac, this would provide a common
graphics interface to many different platforms. Alternatively,
developers could tailor the interfact to the system.)
>
>> If we were to compare the languages
>> pragmatically, based on current implementations, we'd find that
>> Java IDEs generally suck,
>
> Gee, I like symnatec cafe pretty well.
>>
Haven't used that one. My experience with them is that they need
work. Another promise for the future.
>> It's also worth considering the tradeoffs. Java has specified an
>> execution model in considerable detail, in an effort to gain portability.
>> This has two major tradeoffs.
>
> You say tradeoff, but you don't bother to examine what it gains by
>these tradeoffs. Bad argumentation.
>
Um, I did use the word "portability". Java byte code is very portable.
This portability isn't free.
>> First, it complicates implementation.
>> You can't implement Java on a system without coming up with some sort
>> of graphics and threading ability. This, to some extent, inhibits
>> portability, as there are fewer systems that can run it at all.
>
> How absurd. The fact that the implementor has to conform to the
>standard means that once the VM is implemented, the software will be
>portable. The alternative would be to not specify these details, and
>create vast amounts of unportable software.
>
Yup. My attitude is that I've seen this tried before, such as with
the UCSD p-system for Pascal. I haven't seen it work yet. The JVM
may well be the exception, of course. We'll have to wait and see.
The VM has to be created for each platform it will be used on. It's
taken quite some time to get even betas out for Windows 3.1, and that
is not an unpopular platform. If there are bugs in the VM, then,
Java programmers are going to be in trouble.
Nor is that the alternative. There are lots of portable programs in
Lisp or C. I don't know whether it's easier to put Lisp or C or JVM onto
a new platform, but I do know that compiled Lisp and C will outperform
JVM by a good deal.
> Also, what are these systems we are writing software for which do not
>have graphics, nor any mechanism for simulating threads? Incidentally,
>do they have enough memory to run common lisp?
>
MS-DOS will run CLISP very nicely. Heck, I had a reasonable Lisp
for my old CP/M machine. I was a bit limited in application size,
true. This is off the top of my head.
>
>> Second,
>> it can be a big performance hit. If, for some reason, the JVM is not
>> a good fit on a system, it will run very slowly.
>
> Could you give an example of such a system, and show how another
>language would run more quickly, like, say, lisp?
>
Any system that does not conveniently support IEEE floating-point
calculation. Any compiled language will do better than Java on such
a platform. While all mainstream computers coming out now support
that, I'm very reluctant to assume they always will.
>> Even if it is a fairly
>> good fit, it will often be interpreted,
>
> Not true on any newer system/
>
Is there a JIT for the Mac yet that is trustworthy? I can find a beta
one from Apple, or use the one from the Thrill Seekers folder of
Metrowerks. If not, well, MCL has compiled nicely on my Mac for
some time now. Please either make references to released software,
or abandon this thread until you can.
>> and even a just-in-time compiler
>> will probably not bring it up to the speed of a good Common Lisp compiler.
>
> Completely untrue. If it it not already faster( it probably is for a
>lot of applications ) java will certianly be faster after the VM's get
>shaken out.
>
An interesting statement, with no apparent support. My guess is that
there will always be a speed hit for the JVM. It may not be a really
large one, and may be worth it.
>> One large difference is that CL, more than most languages, hides the
>> machine-level semantics. The compiler is free to take the program as
>> the intent of the programmer, and use whatever system-specific
>> shortcuts are available to produce efficient code.
>
> So, based on your argument, Lisp should be very fast, C should be
>slugish, and assembler should be dog-slow. I may be going out on a limb
>here, but this is not verified by my real-life experience.
>
No, because compilers do have limits. Lisp provides very little
guidance, but C is loose enough to allow compilers to work at their
limits. Assembly will run fast or slow, depending on the programmer.
JVM will run slow.
> Particularly for small functions, lower-lever languages will almost
>always win. Sometimes in large programs, higher level languages will
>win ( be faster ) because the abstrctions help us focus on our
>algorithms.
>
Lisp is comparable to C or Fortran, given a bit of source code fiddling.
There is actually some of the same overhead (heavy pointer use and
indirect functions) in both Lisp and Java. I'd suspect that a native
code Java compiler would do about as well as a native code Lisp compiler.
Translating into byte code, you lose much of the ability.
>> Java byte code
>> specifies machine-level semantics in great detail, and so the emulator
>> will generally have to do a lot of extra work.
>
> I get the sneaking suspicion you don't know the bytecode all that
>well. The bytecodes are both simple and high-level, allowing a lot of
>optimizations. They're not perfect, but they're not too bad, either.
>
No, I don't know it that well. I don't have to to know there will be
a performance hit. We're doing a two-step compile here, from Java to
byte code and then from byte code by the JIT compiler, and we're throwing
away information in the process. If it were just as efficient to
compile to byte code, a Lisp or C compiler could do that. Therefore,
Java cannot be more optimizable than Lisp or C, and is probably less.
> Could you perhaps show and example of where lisp could be more highly
>optimized than idiomatic java? ( The last 2 words there rule out tail
>reusrions as an example. )
>
Um, why rule out tail recursions? If you're going to limit the domain
of argument to the stuff that idiomatic Java is good at, isn't that
bad arguing?
>> Once Java is available on as many sorts of systems as Common Lisp is,
>> we can start making more fair comparisons.
>
> One thing we could do is compare the portability of java on the
>available platforms, with some real programs. Are you game?
>
I don't have access to all that many systems. Shall we start with
Mac, Solaris, and MS-DOS? I *might* be able to get my old CP/M
system going again.
David Thornley
Erik Naggum
* James F'jord Lynn
| The point is that LISP (original LISP now) was designed for one thing: AI.
John McCarthy, et al: LISP 1.5 Programmer's Manual starts:
"The LISP language is designed primarily for symbolic data processing.
It has been used for symbolic calculations in differential and integral
calculus, electrical circuit theory, mathematical logic, game playing,
and other fields of artificial intelligence."
"LISP is a formal mathematical language. ..."
just thought I'd make an effort to put the record straight.
#\Erik
--
I'm no longer young enough to know everything.
Henry Baker
In article <5ijq47$sao$1...@darla.visi.com>, thor...@visi.com (David
Thornley) wrote:
> I'm going by the historical record here. The languages that have
> lasted, the ones with histories, are the ones that have evolved.
> COBOL, Fortran, Lisp, C, Basic. The languages that have been
> standardized from the start, such as PL/1 and Pascal, have generally
> not been nearly as successful. Java and Ada are the two current
> success stories of the design process, with Pascal some distance
> behind.
(One little nit: PL/I _wasn't_ standardized until very late in the day,
and by total usage, it can be considered to be a successful language, at
least relative to, e.g., Pascal and Ada.)
I agree with you wholeheartedly about languages that have evolved. In fact,
_standardization kills languages_. Although ANSI standardization improved C for
a few milliseconds, all of the people making improvements then began working
on C++. When C++ became fixed, the people making improvements went on to
Java. And so on.
Lisp survived so long precisely because it continued evolving to meet the
needs of its users. DARPA killed Common Lisp by standardizing it. The
final meetings of the Lisp standards committee were like the Auld Lang Syne
(sp??) scene in the old black-and-white version of the 'Sinking of the Titanic'.
The only standardized human language today is Latin. Need I say more?
David Hanley
David Thornley wrote:
> > There are at least 2 java implementations for windows 3.1.
> >
> OK, how about MS-DOS? You can run CLISP on it; why not Java?
I'm not sure--I haven't looked into that. I sure never
heard anyone 'promise' that, though.. Can yoy run lisp efficently in
a browser?
> > The application I am writing works on at least 7 different platforms as
> >it currently stands. You may ot may not consider this true portability,
> >but I sure do.
> >
> Pretty good. Not as good as, say, ANSI C, but pretty good.
Nope. My application has a graphical user interface, multithreading,
and does a lot of network work. This obviously wouldn't work at all in
ANSI C. And I've had a lot of diffuculty in porting ANSI C before, to
realtively similar platforms.
>
> >> Java does indeed specify some things in its standard that Common Lisp
> >> doesn't, and the reverse is true also. Since the Java standard was
> >> created, while Common Lisp evolved, I'd bet that there's a lot more
> >> gotchas in the Java standard.
> >
> > Okay--can you point some out? While you're at it, can you explain why
> >evolution would lead to fewer gottcha's than design?
>
> No, and that's the point. People have been using and abusing Lisp for
> decades now. We haven't been doing the same for Java. We haven't
> stress-tested the language. It is very possible that Java will
> prove very awkward for some applications that are currently being
> avoided. (No, I don't know what these will be.)
Then I'm afraid I'm not going to buy that arguement. In any case,
there is a set of applications for which Java has proven well-suited at
this point. If there is another type of application for which it is not
well-suited, I won't use it for that. For example, I don't think I'd
use java for signal handler.
If there were a Lisp->Java VM implementation out there when I was
starting my current project, I might well have considered using it, if
it had the tools I needed: forms designer, debugger, integrated
enviornemnt, etc.
Back to an old topic 'why lisp failed in the marketplace', it seems
that the functional language community is aware that functional
languages have some wonderful features--and they do! But many
functional advocates think that that should win everyone over, and
neglect to find out what else programmers want.
My favorite language is SML. If I could use that on my project, I
would. But I have problems getting a compact, fast executable, or an
executable at all, from the systems I have used. I would use lisp too,
if I could make it fit my project specifications.
>
> I'm going by the historical record here. The languages that have
> lasted, the ones with histories, are the ones that have evolved.
> COBOL, Fortran, Lisp, C, Basic. The languages that have been
> standardized from the start, such as PL/1 and Pascal, have generally
> not been nearly as successful. Java and Ada are the two current
> success stories of the design process, with Pascal some distance
> behind.
>
> In other words, I don't know what Java will be like ten years down
> the road. It's likely to be around in some form, but what?
I don't see why that's relevant. It is fufilling a badly-needed role
right now, so people are using it. The design is based off of one of
the most sucessful evolved languages--C++. You could even consider java
an evolutionary ancestor of C++, with a little of lisp thrown in--GC,
runtime checking, etc.
If we're using java++ or something else entirely different in 10 years,
so what? The other realistic chioice for me would be C++ and java lets
me program faster, better, and far more portably.
But it won't be lisp, if the lisp community does not adapt, and pay
attention to what the market wants.
>> [portability snipped ]
> Ummm,
> (defun fact (x)
> (if (< x 2)
> x
> (* n (fact (1- x)))))
> should run on lots more machines than that (assuming I've got it
> right, typing it into a non-Lisp-aware editor).
>
> Oh, you were expecting a graphics program? Sorry, those aren't
> nearly as portable.
Gosh, the button program must be a figment of my imagination. I guess
a portable gui is impossible.
Are you trying to state that lisp is good for toy factorial programs
and not much else? I hope not.. Because not too many people are going
to want toy factorial programs. You need gui, networking, file access,
threads, and lots more.
>> Symantec cafe is pretty good.
>>
> Haven't used that one. My experience with them is that they need
> work. Another promise for the future.
You may think so, but it is allowing me to do something, today, which
you seem to be stating cannot be done; writing portable real-world
applications in a standardized language.
>>[ bytecode snipped ]
> >
> Yup. My attitude is that I've seen this tried before, such as with
> the UCSD p-system for Pascal. I haven't seen it work yet.
Well, I guess you're never going to see it work, if you allow your
biases to decide what you're going to see. The future of software goes
to those who write software. My current project is in java, it is
portable, and it workes extremely well. The fact that you have problems
with the theory
seems silly, in the face of evidence of functioning software.
> It's
> taken quite some time to get even betas out for Windows 3.1, and that
> is not an unpopular platform. If there are bugs in the VM, then,
> Java programmers are going to be in trouble.
And if there are problems in the Lisp or C compiler, the programmers
are going to be in trouble. Please.
>
> Nor is that the alternative. There are lots of portable programs in
> Lisp or C.
Can you point out some portable real-world appliations? And I dont
mean source with a lot of conditionals. I just want a binary that runs
on a lot of different machines. Remember, real applications nowadays
need graphics, and probably network awareness as well.
> I don't know whether it's easier to put Lisp or C or JVM onto
> a new platform, but I do know that compiled Lisp and C will outperform
> JVM by a good deal.
How do you 'know' this?
> > Could you give an example of such a system, and show how another
> >language would run more quickly, like, say, lisp?
> >
> Any system that does not conveniently support IEEE floating-point
> calculation. Any compiled language will do better than Java on such
> a platform.
How and why?
>
> >> Even if it is a fairly
> >> good fit, it will often be interpreted,
> >
> > Not true on any newer system/
> >
> Is there a JIT for the Mac yet that is trustworthy?
Our application runs on a mac as well, in Netscape or IE.
> Please either make references to released software,
> or abandon this thread until you can.
>
> >> and even a just-in-time compiler
> >> will probably not bring it up to the speed of a good Common Lisp compiler.
> >
> > Completely untrue. If it it not already faster( it probably is for a
> >lot of applications ) java will certianly be faster after the VM's get
> >shaken out.
> >
> An interesting statement, with no apparent support. My guess is that
> there will always be a speed hit for the JVM. It may not be a really
> large one, and may be worth it.
The support comes from knowing how lisp and JVM get compiled. Java
basic types, for example, are always unboxed, while lisp often has to
box types, especially reals. In many cases, the boxing expenses are
greater than the actual computations taking place. Also, because of
continuations, lisp will usually make call frames on the heap, instead
of on a stack. Java can, in some cases, inline or more direct
dispatches instead of dynamic ones, where lisp would have to compute the
target function.
Compared to C++, Java has 2 reasons it may be slower: typed casting,
and array bounds-checks. Incidentally, lisp 'pays' for both of these as
well. Research has shown that these can be optimized away in many/most
cases by static analysis of the code. Lisp compilers do this as well;
type inference can often speed lisp programs by many times. Java has
reasons why it may be faster than C++; lack of pointers to basic types
rule out aliasing in many more cases, allowing more agressive
optimizations in numerical code. The 'final' keyword allows direct
jumps to be used where a virtual dispatch may have been required.
Now, once again, I'm not arguing that java is 'better' than lisp, but
that the lisp community will do itself a great disservice by thumbing
it's nose at genuine software eingineering advances.
>
> >> One large difference is that CL, more than most languages, hides the
> >> machine-level semantics. The compiler is free to take the program as
> >> the intent of the programmer, and use whatever system-specific
> >> shortcuts are available to produce efficient code.
> >
> > So, based on your argument, Lisp should be very fast, C should be
> >slugish, and assembler should be dog-slow. I may be going out on a limb
> >here, but this is not verified by my real-life experience.
> >
> No, because compilers do have limits. Lisp provides very little
> guidance, but C is loose enough to allow compilers to work at their
> limits. Assembly will run fast or slow, depending on the programmer.
> JVM will run slow.
Again, I really don't think you understand compiler optimizations very
well. Lisp may run very fast indeed if the optimizer can use it's
symbolic nature to rewrite expressions.
Interestingly, the java VM is stack-based, much like forth, and a
mirror of the typical lisp structure. A grad paper I read ( I forget
who by ) showed that forth could be optimized to run as fast as C. And,
don't forget, most compilers translate source code into a stack-based
intermediary form before optimization--and this intermediary form looks
a lot like java bytecode.
>
> >> Java byte code
> >> specifies machine-level semantics in great detail, and so the emulator
> >> will generally have to do a lot of extra work.
> >
> > I get the sneaking suspicion you don't know the bytecode all that
> >well. The bytecodes are both simple and high-level, allowing a lot of
> >optimizations. They're not perfect, but they're not too bad, either.
> >
> No, I don't know it that well. I don't have to to know there will be
> a performance hit.
Of course not. How silly of me.
> We're doing a two-step compile here, from Java to
> byte code and then from byte code by the JIT compiler, and we're throwing
> away information in the process.
Really? What information, exactly?
> If it were just as efficient to
> compile to byte code, a Lisp or C compiler could do that. Therefore,
> Java cannot be more optimizable than Lisp or C, and is probably less.
Almost every C compiler produces an intermediary form. The GNU C
compiler, for example, has an intermediary form that can be produced by
several front ends, and can be compiled for several targets. In the
book 'fundamentals of lisp' ( a very good book ) there is a stack-based
inermediary form that their lisp compiler uses.
>
> > Could you perhaps show and example of where lisp could be more highly
> >optimized than idiomatic java? ( The last 2 words there rule out tail
> >reusrions as an example. )
> >
> Um, why rule out tail recursions? If you're going to limit the domain
> of argument to the stuff that idiomatic Java is good at, isn't that
> bad arguing?
No, I was just trying to state, ( perhaps not too clearly ) that
writing a tail-recursive lisp & java function would be silly, when the
idiomatic way would have been to write a loop. I notice you didn't
provide an example... How about:
(defun fact (x)
(if (< x 2)
x
(* n (fact (1- x)))))
int fact( int x )
{
int n;
for ( n = x ; x > 2 ; -- x )
n = n * x;
return n;
}
As a clear example of what I mean by 'idiomatic'?
dave
Firth, Reginald J.
In article <slrn5kiilh....@turbonet.com>,
Mark 'Kamikaze' Hughes <kami...@kuoi.asui.uidaho.edu> wrote:
>David Thornley <thor...@visi.com> spake:
>>reasonable form of Common Lisp runs on and Java doesn't, such as
>>Windows 3.1 systems.
>
>
> Try another example.
>
<< Is that out of beta yet? If so, how about MS-DOS? CLISP does a nice
<< job there of being a free Common Lisp. Has Java been ported to
<< everything CMU-CL has been ported to? I suspect that you'll find
<< platforms with Gnu Common Lisp and no Java for a long time.
Jarva is totally transparent to the physical IEEE v1 protocol thus it is
no use in modern systems
<< In other words, Common Lisp source code is more portable than
<< Java source or byte code. I expect this to be true for a long time
<< to come.
>>If we were to compare the languages
>>pragmatically, based on current implementations, we'd find that
>>Java IDEs generally suck, there's major problems with 1.0.2 AWT,
>>and so forth.
>
> As opposed to the incredibly powerful and universally portable IDEs and GUI
>libraries included as part of Common Lisp.
>
<< Powerful, yes. Portable, well, that depends. CLIM is commercial but
<< runs on Windows and Unix. Garnet is free, if unsupported, and runs on
<< Mac and Unix. IDEs vary.
IDEs are also totally transparent
<< Look, I'm not knocking Java, just the hype associated with it.
I agree. Use a real "language" if it can be called thus
<< Java, right now, is of limited portability. This is likely to change,
<< but porting the JVM to some environments seems to be difficult.
<< Further, this portability comes with some massive costs in
<< performance,
<< and possibly reliability. This isn't part of the standard, but it's
<< true nonetheless.
"Porting" to alleviate code deficiencies is totally laughable
<< David Thornley
Reg Firth
Senior Lecturer - Comp Sci
Firth, Reginald J.
Jason Trenouth wrote:
> The language. I believe (correct me if I'm mistaken) that in Java, the stack
> is unwound _before_ a handler runs. This makes some kinds of recovery much
> clumsier than in Common Lisp, where the handler can run with all the context
> of the signaller.
>> Yes, for exception handlers Java has termination semantics, not
>> resumption semantics. See "The Design and Evolution of C++" (by Bjarne
>> Stroustrup), section 16.6. He discusses at length why they choose
>> termination semantics for C++ (and the reasons given include >> significant
>> real-world experience with both kinds of semantics). All the same
>> arguments apply for Java.
You are not serious or have a severe lack of understanding on the subject
on which you are speaking about. I fear the latter.
> > I don't know what you mean by "no real dynamism".
>
> In this case I meant sometimes having to explicitly tell the compiler what the
> type is (via a cast) in order get something to work (again, correct me if I'm
> misinformed). In languages like Common Lisp and Dylan, adding explicit typing
> doesn't change the semantics of the program: it only improves its performance
> or error checking.
<< The fact that you have to sometimes specify a cast isn't (IMHO) a
<< reduction of dynamism, and it allows static type-checking. You still
<< get dynamic binding, which is "real dynamism".
In your humble opinion...good thing you added that because what you are
saying has no founding. You do not get dynamic binding. Try and explan to
me why you think it does and I shall correct you.
Erik Naggum
* Henry Baker
| In fact, _standardization kills languages_.
this is a curious way to look at things. standardization _should_ happen
after all the experimentation and evolution has been reduced to near zero.
of course, since most of those who work with standardization are fully
aware that proper standardization should _not_ add tons of features to a
mature language. some consider this symptoms of death, others of
stability. as anybody who has seen committees invent a lot of bogosity
during the standards process would know, standardization processes that do
_not_ kill a language in this way are the really dangerous ones.
| The only standardized human language today is Latin. Need I say more?
it seems that you have a problem with standardization as such. this is not
productive. standardization is supposed to take place _after_ development
activity has been falling, and _before_ commercialization takes off.
see http://www.javasoft.com/people/jag/StandardsPhases/index.html for a
good summary of the problems of untimely standardization.
Rainer Joswig
> Jason Trenouth wrote:
>
> > The language. I believe (correct me if I'm mistaken) that in Java, the stack
> > is unwound _before_ a handler runs. This makes some kinds of recovery much
> > clumsier than in Common Lisp, where the handler can run with all the context
> > of the signaller.
>
> Yes, for exception handlers Java has termination semantics, not
> resumption semantics. See "The Design and Evolution of C++" (by Bjarne
> Stroustrup), section 16.6. He discusses at length why they choose
> termination semantics for C++ (and the reasons given include significant
> real-world experience with both kinds of semantics). All the same
> arguments apply for Java.
I never believed in what I read in "The Design and Evolution of C++".
He talks about experience from TI Explorer. Well, my
experience with Genera (an OS actually using such stuff, too) and
MCL is different. I mean, correcting an error situation and
being able to *just* continue seems so obvious to me.
"exception handlers with calling semantics" are clearly
easier to use and more powerful.
> The fact that you have to sometimes specify a cast isn't (IMHO) a
> reduction of dynamism, and it allows static type-checking. You still
> get dynamic binding, which is "real dynamism".
You mean "dynamism" where you change classes, an object's class,
change the implementation of a class, choose different method
combinations, add methods, delete methods, etc. is not "real"?
Not everyone needs it, but evolvable and adaptive systems
may.
Barry Margolin
In article <30697628...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>this is a curious way to look at things. standardization _should_ happen
>after all the experimentation and evolution has been reduced to near zero.
But in the real world of computers, evolution rarely stops. Lisp was over
30 years old when Common Lisp was developed, and innovation was still being
done by X3J13 (CLOS is essentially an invention of a subcommittee of this
group, although it is mostly an amalgamation of existing technologies such
as Flavors).
Deciding when to standardize is like deciding when to release a software
application. If you say, "we're not going to ship until all the features
are in and all the bugs are out" then you may never have a product -- you
can always think of more features to add, and as long as you're adding
features you're also adding bugs. So eventually you decide "we need to get
something out the door -- what we have is good enough, and then we'll start
working on release 2.0."
--
Barry Margolin
BBN Corporation, Cambridge, MA
bar...@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
Cyber Surfer
With a mighty <334E77...@nospan.netright.com>,
da...@nospan.netright.com uttered these wise words...
> But it won't be lisp, if the lisp community does not adapt, and pay
> attention to what the market wants.
I've been saying this for the last couple of years, and I suspect that
it makes me rather unpopular with some people. This is why I welcome
Dylan, and anything like it. Perhaps it's a little agressive for a few
of us, but we shouldn't be suprised by the ways in which Dylan departs
from the Lisp orthodoxy, esp if we consider where the funding for
Dylan came from.
In the same way, we might better appreciate the direction that Common
Lisp is coming from by looking at the funding, and the goals & agenda
that imlies. Apple and ARPA needed very different things. This should
now be clear from the new direction Apple are taking, by apparently
abandoning Dylan. I hope that the language is in better hands, now.
As for Common Lisp, I don't know. To be fair, we should look ahead
another 15+ years, as CL won't be going away, and the machines that CL
runs on won't stop improving, nor will the demands on software
decrease. I think that we've reached a point where languages like Java
are unavoidable, and we may well reach the point where Lisp is also
recognised.
However, I doubt this will happen if, 15 years from now, Lisp is still
the ANSI Common Lisp that we know today. If CL hadn't changed at all
during the last 15 years, how many of us would be using it today? A
few, at least, but many of us might be concerned by the lack of
progress, and the demands that were not being met by the language.
As for implementations, this will depend on the market. I'm only
looking at commercial implementations, as the free systems are not
limited by what the market will pay for, but only by what implementors
can achieve, and that's much harder to predict.
Should we only consider the Lisp market? If that's defined by what
Lisp vendors offer, then it really depends on the _vendors_, and what
they say their customers ask from them. If this is the case, then I'm
not sure that comparing Lisp with any other language is particularly
meaningful, unless a significant number of these customers are looking
at alternatives to Lisp, and still (it seems) choosing Lisp.
Meanwhile, there are others who may care less about the language, and
more about how well it _appears_ to satisfy their demands. In other
words, the choice is made by how marketing presents the product. The
language itself may be irrelevant! This isn't as bad as it may sound,
as it suggests that _any_ language may be packaged and presented in a
sufficiently positive manner. (E.g. DylanWorks? Tcl? Java?)
In the past, this technique has worked very well for C++ and Basic.
It's currently working superbly for Java. What's next?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Henry Baker
> * Henry Baker
> | In fact, _standardization kills languages_.
>
> this is a curious way to look at things. standardization _should_ happen
> after all the experimentation and evolution has been reduced to near zero.
I agree wholeheartedly with this statement. So long as we keep experimenting
and evolving, we can keep the language lawyer's mitts off the language.
David Hopwood
In message <334E77...@nospan.netright.com>
David Hanley <da...@nospan.netright.com> writes:
[...]
> No, I was just trying to state, ( perhaps not too clearly ) that
> writing a tail-recursive lisp & java function would be silly, when the
> idiomatic way would have been to write a loop. I notice you didn't
> provide an example... How about:
> (defun fact (x)
> (if (< x 2)
> x
> (* n (fact (1- x)))))
> int fact( int x )
> {
> int n;
> for ( n = x ; x > 2 ; -- x )
> n = n * x;
> return n;
> }
Just thought I'd point out that neither of these are correct. They should be
something like:
(defun fact (x)
(if (< x 2)
1
(* x (fact (- x 1)))))
long fact(long x) {
long n;
if (x > 20)
throw new IllegalArgumentException();
// or use BigIntegers if necessary
for (n = 1; x > 1; --x) {
n = n * x;
}
return n;
}
David Hopwood
david....@lmh.ox.ac.uk, hop...@zetnet.co.uk
Christopher Stacy
No system is ever fully debugged and documented
until the last user is dead.
Erik Naggum
* Henry Baker
| In fact, _standardization kills languages_.
* Erik Naggum
| this is a curious way to look at things. standardization _should_ happen
| after all the experimentation and evolution has been reduced to near zero.
* Henry Baker
| I agree wholeheartedly with this statement. So long as we keep
| experimenting and evolving, we can keep the language lawyer's mitts off
| the language.
_why_ this extreme hostility to standards and "language lawyers"?
let me make some random guesses: (1) you hate precise definition of things.
(2) you despise agreements involving many people. (3) you loathe languages
that are the same from one machine to another. (4) you feel personally
offended if a program works the same way from one week to another. (5) you
feel unduly constrained by specifications and would prefer if people stop
making demands on your code. (6) the stability required by a standard is
a personal affront to your "creativity".
I'm just home from another curious experience in incompatibility. I have a
Lisp system at home (my trusty SPARCstation), but a client of mine wanted
NT, so they bought a Lisp that works in The World According to Gates, where
quality is not an issue. both purport to be Common Lisp, but this NT thing
is pre-CLtL1 with some CLtL2-isms thrown in for good measure, such as
rejecting (mapcar (lambda ...) ...) as an "unquoted lambda form" despite my
having introduced the `lambda' macro straight from Common Lisp the
Standard. code that I have proved correct (relative to CLtS) and which
worked beautifully on my home system, failed with a memory reference
violation and a crash under NT. the other day, I discovered that although
numerous ~/<function>/ forms are available in `format', that doesn't mean
~/<user-function>/ works. no, no, ~/<function>/ is a _very_ special case
for built-in functions, only. to call user functions from within `format',
one must use the ~vQ format control, which is of course non-standard and
really weird, too. no matter, this is Windows, so if there are standards
and language lawyers, screw them! I'm sure you must be a great fan of Bill
Gates, Henry. he's certainly the antithesis of a language lawyer, and the
very embodiment of "experiment and evolve". (well, maybe not "evolve".)
however the world of programming is viewing specifications and standards,
_I_ want to program in a _language_ according to its _specification_, _not_
a mere implementation of something-or-other. this is not possible without
a reasonably formal specification with reasonable consensus behind it to
hold an implementation up against. (this is the original meaning of
"standard".) in fact, I want to be able to trust a specification enough to
not have to test for everything myself when I want to use an implementation
that purports to follow it. this is what language lawyers make sure is
possible. this is why I _embrace_ language lawyers.
of course, there wouldn't be any criminals if it weren't for the laws, so
there's always a downside to it all, depending, of course, from which side
of the the law you look at it. I'm sure criminals also would like lawyers
to keep their mitts off their livelihood.
David Thornley
In article <hbaker-1004...@10.0.2.1>,
Henry Baker <hba...@netcom.com> wrote:
>In article <5ijq47$sao$1...@darla.visi.com>, thor...@visi.com (David
>Thornley) wrote:
>
>I agree with you wholeheartedly about languages that have evolved. In fact,
>_standardization kills languages_. Although ANSI standardization improved C for
>a few milliseconds, all of the people making improvements then began working
>on C++. When C++ became fixed, the people making improvements went on to
>Java. And so on.
>
C is one heck of a better tool than it would be if it had not been
standardized. As somebody else pointed out, it's much like releasing
a version of a program. It will lock future versions into undesirable
choices, and will not be as good as it could be, but nobody can use
it effectively until it's released. In the second place, standardization
slows innovation, not stops it. There are dozens of small changes
that may well go into the next C standard, some of which came from
C++/Java/whatever, and some of which were home-grown.
>Lisp survived so long precisely because it continued evolving to meet the
>needs of its users. DARPA killed Common Lisp by standardizing it. The
>final meetings of the Lisp standards committee were like the Auld Lang Syne
>(sp??) scene in the old black-and-white version of the 'Sinking of the Titanic'.
>
I think Common Lisp is tougher than that. I find the things you can do
with macros amazing. It is possible to transform the nature of the
language in a form that runs easily on any standard implementation.
If you want to add Prolog-style processing, or an entirely different
object model, you can do that. It isn't easy, but people do it.
Stroustrup said of C++ that "Library design is language design",
and that applies even more to Lisp.
>The only standardized human language today is Latin. Need I say more?
You left out official French, which looks to me like an attempt at
reverting to the old days in Norman England or Tsarist Russia when
the aristocracy spoke French and the commoners didn't. I agree
strongly that standardization doesn't work for human languages.
I think it will work for Common Lisp and C++ and other flexible
languages.
David Thornley
Moribund
Christopher Stacy <cst...@pilgrim.com> wrote in article
<uhghan...@pilgrim.com>...
> No system is ever fully debugged and documented
> until the last user is dead.
>
Amen...though I would add that no system is ever fully complete until the
last (dead) user's machine is removed from the shop.
Damo
Henry Baker
> * Henry Baker
> | In fact, _standardization kills languages_.
>
> _why_ this extreme hostility to standards and "language lawyers"?
>
> let me make some random guesses: (1) you hate precise definition of things.
> (2) you despise agreements involving many people. (3) you loathe languages
> that are the same from one machine to another. (4) you feel personally
> offended if a program works the same way from one week to another. (5) you
> feel unduly constrained by specifications and would prefer if people stop
> making demands on your code. (6) the stability required by a standard is
> a personal affront to your "creativity".
The problem with standards is that they take a previously 'open' system and
'close' it. Perhaps this isn't an essential characteristic of standards, but
this has been the experience of standardization in the past.
Standards are usually promulgated by customers in collusion with the 2nd,
3rd, and 4th vendors in a market. The idea is to gang up on the 1st vendor
and force him to eliminate any features which will give him an advantage.
The 2nd, 3rd and 4th vendors want to incorporate as many of their incompatible
features as possible to raise the barriers to entry of the 5th, 6th, etc.,
vendors into the market. The problem with this approach is that while it
assures a little market stability and profitability for the 1st through the
4th vendors for a little while, it destroys the market as a whole, because
the thing standardized can no longer evolve to fit new uses and grow the
overall market. Thus, like parasites on a host, the parasites thrive for
a while until the host dies, then the parasites die.
The most obvious examples of standards which have outlived their usefulness
for decades or more are the NTSC television standards and the 2-prong
electrical plug standard.
Marc Wachowitz
Henry Baker (hba...@netcom.com) wrote on standards:
> The idea is to gang up on the 1st vendor
> and force him to eliminate any features which will give him an advantage.
> the thing standardized can no longer evolve to fit new uses and grow the
> overall market.
For a reasonably powerful programming language, I don't see how that
could be done - even if that would be the purpose of some co-worker
in the standardization process. All some more expressive system needs
to do is to provide its extensions such that programs expecting the
standard environment (which includes to remain within the promises of
the standard) fail due to the difference. At in least those recent
programming language standards of which I know, there's even some more
or less offficial way how extensions could look like to work well
with conforming programs (e.g. reserving some part of the name space
for the implementation, or simply add a few modules). Even where that
isn't available, technically speaking, you can always get away by
defining a particular invocation of the language processor as the true
standard tool, and make your (nevertheless carefully integrated) fine
extensions available only where requested. You can even make your "big"
variant the default, and just provide something like gcc's -pedantic
for those who want it, including potential conformance testing and the
language lawyers. Particularly with Lisp's expressiveness, I don't see
how this would limit anyone's creativity in the technical area (using
a different name or package binding for an extension where the standard
requires to signal an error shouldn't be a problem). Of course, if the
problem is that nobody cares (or pays ;-) any more for anything beyond
the limits of the standard, that has much more to do with the mentality
of the vendors or the user community or the financial situation of the
market - which are hardly the fault of having a standard. If you think
there's something e.g. in the Common Lisp standard which prevents the
addition of a particular great idea, which couldn't be integrated in
any useful way due to the standard, I'd be interested to hear what this
would be. (Obviously, adapting the interface of some pre-standard way
to access a particular facility may always be needed, but I think that
the benefits of a reasonable standard for the users tends to outweight
such efforts in almost all cases.)
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Richard Pitre
I have a feeling that you could kill all of the C/C++/Java/(other
assorted technojoyusness)
programmers and their families
and nuke the shops that their machines are in with the net result that
some brilliant opportunist would introduce a more superduperer language
that is so wonderful that objects are simplistic passe' little
whimpyassed whanker dodads compared to the ballbustin forever
badassedness of the new gizzmos in this new PC language for PCs that
lets you do everything without doing anything and whose
grammer could only be expressed as the output of
a nonterminating process that a committee will someday define.
You know what I mean, a language that doesn't require you to know how to
do anything in order
to implement all of the things that you do know how to do. You just feed
a steady stream of
meaningless unreadable kaka to a parser god and it even tells you on
which line you useless
meaningless kaka smells worse than the useless meaningless kaka on the
other lines.
William Clodius
Henry Baker wrote:
> <snip>
> The problem with standards is that they take a previously 'open' system and
> 'close' it. Perhaps this isn't an essential characteristic of standards, but
> this has been the experience of standardization in the past.
>
> Standards are usually promulgated by customers in collusion with the 2nd,
> and force him to eliminate any features which will give him an advantage.
> features as possible to raise the barriers to entry of the 5th, 6th, etc.,
> vendors into the market. The problem with this approach is that while it
> assures a little market stability and profitability for the 1st through the
> 4th vendors for a little while, it destroys the market as a whole, because
> a while until the host dies, then the parasites die.
The above theory sounds nice, but it makes the standards process (for
programming languages) sound even more rational and constraining than it
actually is. Things that have occurred in the standards process (see
Computer Standards and Interfaces Vol 16 Nos 5/6, September 1994, a
special issue devoted to language standardization.)
1. The representative of the primary vendor suggests a number of
additions to the language that are adopted in the standard. The vendor
then refuses to implement those additions. (I believe this was true for
IBM either for PL/I or APL)
2. The standard does not adopt the practices of the major vendor. The
major vendor ignores the standard and does fairly well while everyone
else collapses. Pascal and perhaps PL/I.
3. The extensions of the major two vendors are not adopted by the
standard, but everyone (20+ vendors) adopts almost all the extensions
that are at all portable anyway. Fortran 77
4. The standard ignores almost all common extensions and adds a ton of
stuff not supported by any of the vendors. The vendors (almost 20 of
them) somehow manage to retain most of their extensions and add the new
capabilities. Fortran 90
5. The standard attracts a lot of academics that ignore common practice
and use the language standard as a testbed for formal definitions. The
committee chair disappears in the midst of the standardization process.
Modula 2.
6. The standards process seems to take on a life of its own, taking at
least a decade to reach an end, adding more and more features (and odd
constraints) resulting in something incomprehensible. The result is
apparently widely popular and commercially profitable for a number of
vendors. C++ (and to a lesser extent PL/I and Fortran 90)
--
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: wclo...@lanl.gov
Bruce R Miller
In article <hbaker-1004...@10.0.2.1>,> ...
>The only standardized human language today is Latin. Need I say more?
Latin is standardized precisely _because_ it is dead, _not_ the reverse.
(besides, it wasn't `standardized' it simply stopped).
And I suspect that reverse explanation applies to many cases you are
interpreting as `standardization killing (computer) languages' too.
Perhaps many cases are simply where a language was already doomed and
proponents had hoped to revive or prolong it by standardizing it?
Although Lisp arguably was alive when standardization started, it was
`dead' _before_ it got standardized. I think standardization was the
least likely cause. Indeed, it took so long to standardize because it had
evolved for so long in too many directions _before_ the effort began
and before Lisp ever gained a foothold in the mainstream.
That is, I'd say _lack_ of standardization more likely contributed
to its death, than standardization did! (but neither is `the' cause)
Neither F66 nor F77 killed or stifled Fortran. And, if people around here
are any indication (and I doubt they are :>), F90 is reviving fortran
rather than killing it.
What about Java? Currently, its standardization process is benevolent
consultative caveat, rather than Committee --- does that still count? :>
At any rate, without additional standards (however established), I doubt
it will succeed. For example, in spite of the effort Netscape & Microsoft
put into IFC & AFC, resp., it is better for Java as a whole for Javasoft to
Proclaim JFC the standard.
--
bruce....@nist.gov
http://math.nist.gov/acmd/Staff/BMiller/
Moribund
Richard Pitre <rpi...@ziplink.net> wrote in article
<335439F7...@ziplink.net>...
> I have a feeling that you could kill all of the C/C++/Java/(other
> assorted technojoyusness)
> programmers and their families
> and nuke the shops that their machines are in with the net result that
> some brilliant opportunist would introduce a more superduperer language
> that is so wonderful that objects are simplistic passe' little
> whimpyassed whanker dodads compared to the ballbustin forever
> badassedness of the new gizzmos in this new PC language for PCs that
> lets you do everything without doing anything and whose
> grammer could only be expressed as the output of
> a nonterminating process that a committee will someday define.
> You know what I mean, a language that doesn't require you to know how to
> do anything in order
> to implement all of the things that you do know how to do. You just feed
> a steady stream of
> meaningless unreadable kaka to a parser god and it even tells you on
> which line you useless
> meaningless kaka smells worse than the useless meaningless kaka on the
> other lines.
>
Exactly...when are these language designers going to get it straight?!?
:)
Erik Naggum
* Henry Baker
| The problem with standards is that they take a previously 'open' system
| and 'close' it. Perhaps this isn't an essential characteristic of
| standards, but this has been the experience of standardization in the
| past.
this statement puzzled me for a while. then I realized that the problem is
that standardization is entirely unrelated to this process. the history of
any evolving technology is one of closing. what standardization does is to
force this closing to take place in stricter ways than the randomness of
the market.
| Standards are usually promulgated by customers in collusion with the 2nd,
| 3rd, and 4th vendors in a market.
this joke betrays your lack of experience with standardization more than
anything else. these silly conspiracy theories have no grounds in fact,
and look like you are grasping for ways to communicate your emotional
response to standardization to others through sufficiently vile examples.
| The most obvious examples of standards which have outlived their
| usefulness for decades or more are the NTSC television standards and the
| 2-prong electrical plug standard.
I'm not sure of precisely what these two are supposed to be examples, but
you may find it instructive to consider something quite different from
standardization as the cause of the recalcitrance to switch over to better
technology: the installed base. standards cannot make demands on the
installed base without solid support from all the vendors. if they don't
get it, maybe it's not a good idea to change for the sake of change?
you seem to be railing against a society in growth in general, and have
targeted standardization only because it seems the less informed in your
audience will believe it to be the cause of the ills you describe. the ill
is not standardization, the ill is the way human beings strive to protect
their investments in time over time. the symptom you attack is one that is
very good at protecting such investments: if you think standards are evil,
you should not argue against standards, you should argue against the need
to protect investments of the past. you should ask people to abandon their
homes and jobs and go look for something better, because their current
homes and jobs are certainly no match for your dreams of what life could be
like.
the world is not perfect. it won't be. however, standardization aims to
make it less imperfect than it would be without the consensus that the
standardization process aims to get. of course, standards are perfect,
either. some of them downright _stink_. but you cannot sit on your fat
ass and cry about standardization "closing previously open systems" and do
nothing about it. get up there and get involved!
you have argued so strongly against standardization that I challenge you to
provide a viable alternative. surely you must have _something_ to offer.
Erik Naggum
standardization process aims to get. of course, standards are not perfect,
Mark L. Watson
Sorry for the SPAM, but I have to add my 2 cents worth (I have
written two LISP books for Springer Verlag, and I am finishing my
second Java book for MKP) re: Java v. LISP vs. standards a good thing?
First: Java vs. LISP: Java now (with the JDK 1.1) has much of the good
stuff from the LISP world. For example, Java introspection is similar to
CLOS (Common LISP object system) meta-object protocol for introspection.
Java inner (i.e., nested) classes are similar in spirit to lexically
scoped
functions in Common LISP and Scheme. Both languages save mega
programmer time by supplying garbage collection (but when will Java
have ephemeral or generational garbage collection?).
Second: Standards: This is really just an opinion: it seems like the
best standards start out as either university 'experiments' or proprietary
products that eventually evolve into standards. For example, after years
of porting LISP code between different implementations, it was great
to get a single high-quality LISP: Commn LISP. For me, Java is
a universal language like Common LISP: available on all platforms,
and great fun to work with.
Also: re: standards reducing creativity: hog-wash. The "creativity space"
in computer science is infinite; some languages might be better tools
than others (especilly in specific domains), but really, who is really
limited by their programming language?
Mark Watson
http://www.markwatson.com/
Henry Baker
> * Henry Baker
> | Standards are usually promulgated by customers in collusion with the 2nd,
> | 3rd, and 4th vendors in a market.
>
> this joke betrays your lack of experience with standardization more than
> anything else. these silly conspiracy theories have no grounds in fact,
> and look like you are grasping for ways to communicate your emotional
> response to standardization to others through sufficiently vile examples.
Just peer into the standardization processes going on in the networking
and high-definition television communities. This is hard-ball marketing
in its rawest form.
Erik Naggum
* Henry Baker
| Just peer into the standardization processes going on in the networking
| and high-definition television communities. This is hard-ball marketing
| in its rawest form.
Henry, really, we can all find examples of evils, but it is your claim that
such _is_ standardization and that standardization _usually_ works this way
that is ridiculous. it's just like the IRS is perceived by some as Evil
incarnate because of their experience with its tentacles, but the rest of
the population can't relate to any of the horror stories. it does you no
good to scream and shout that the IRS is out to destroy the whole nation
when you have a problem with their treatment of you or people you know.
it really behooves you to investigate whether there are other culprits than
standardization in the crimes to humanity that you so strongly object to.
I think you will find that standardization has added insignificantly to the
evils of the world, and has actually alleviated quite a few ills. it is no
guarantee against human errors, of course, but just like the saying goes:
that to err is human but it takes computers to screw up big time; to make
_really_ costly errors, you need a standard -- or the free market. but to
_avoid_ really costly errors, you _also_ need a standard, only you don't
know whether a standard will save you a lot or cost you a lot until way
after it has been completed. this is no different from anything else with
a moderate to long time span, so I also fail to see the point in rubbing
the standardized nose in the flops.
#\Erik
--
Bastard Sex Therapist from Hell: "Read the F*cking Manual!"
Bruce Koerner
Henry Baker wrote:
>
> In article <30704628...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>
> > * Henry Baker
> > | Standards are usually promulgated by customers in collusion with the 2nd,
> > | 3rd, and 4th vendors in a market.
> >
> > this joke betrays your lack of experience with standardization more than
> > anything else. these silly conspiracy theories have no grounds in fact,
> > and look like you are grasping for ways to communicate your emotional
> > response to standardization to others through sufficiently vile examples.
>
> and high-definition television communities. This is hard-ball marketing
> in its rawest form.
Possibly true, but the purpose of standardization is to promote the
technology through enabling a wider audience to benefit. Naturally
companies push to get their variants into the standards; but if it didn't
work, the trend setters wouldn't co-operate and leave everyone else in
the dust. Usually the industry leaders are in the process too.