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".