Prolog vs. Lisp
Gary
I am looking for a comparison between Prolog and Lisp in terms of
the problem domains of each language.
is there a text on the net? Magazin?
Thanks
Gary
Susan Fisher RSTC Contractor
I have a similar question. I am taking an AI course where we may
program in any language we choose. I debating the use of C, C++,
and LISP. I am looking for any insight on the pros and cons of
these languages. I am a very new programmer and have honestly
never had the option of which language to use! And advice
would be greatly appreciated.
Susan
John Nagle
Susan Fisher RSTC Contractor <sfi...@felix.cc.gatech.edu> writes:
>Gary wrote:
>> I am looking for a comparison between Prolog and Lisp in terms of
>> the problem domains of each language.
>> is there a text on the net? Magazin?
>> Thanks
>I have a similar question. I am taking an AI course where we may
>program in any language we choose. I debating the use of C, C++,
>and LISP. I am looking for any insight on the pros and cons of
>these languages. I am a very new programmer and have honestly
>never had the option of which language to use! And advice
>would be greatly appreciated.
Well, for starters, they're both nearly dead languages, although
Prolog is deader.
Prolog is useful for a limited class of problems that are
expressable in its rule form, and almost useless for anything else.
I once wrote a program to configure PC hardware in Prolog; the
algorithm was suprisingly easy, but the menu system was painful,
because it needed sequentiality.
LISP is sort of like Java, but with more parentheses. Really.
Both languages have dynamic allocation, garbage collection,
safety at run time, and the ability to load new code while
running. Any algorithm you can write in LISP you can probably
write about equally well in Java. Java is more strongly typed
than LISP; in Java, typing is mandatory, while in LISP, it's
optional in the same sense that it's optional in Visual Basic.
[Please, no flames from the LISP fanatics. I've used Franz LISP,
Interlisp on DEC-10s, Common LISP, and the refrigerator-sized Symbolics.
It's over. Let it go.]
John Nagle
reeves
John Nagle wrote:
> Well, for starters, they're both nearly dead languages, although
> Prolog is deader.
> ....Prolog has logic variables and difference lists.
It's dead, like Latin.
Ray Reeves
Erik Naggum
* Susan Fisher RSTC Contractor
| I have a similar question. I am taking an AI course where we may program
| in any language we choose. I debating the use of C, C++, and LISP. I am
| looking for any insight on the pros and cons of these languages. I am a
| very new programmer and have honestly never had the option of which
| language to use! And advice would be greatly appreciated.
rest assured that someone will come along and proclaim Lisp dead or that
they can't use it. this is really only a reflection of their own attitude,
_possibly_ only envy for those who can still use it for fun and profit, and
has nothing to do with the language. you will find similar "reasons" not
to use any other language, too. Common Lisp was approved as ANSI Standard
on 1994-12-08. the vendors in the Lisp market are growing.
C is very close the actual processor, which means you get to do everything
yourself. while the model of the processor that C employs is long gone,
the simplicity of the model still makes is possible to be fairly certain of
how the machine will respond to your instructions. this gives programmers
a feeling of "control" that is very intoxicating. it is also easy to
confuse this "control" with "efficiency", but computers are not efficient
in intuitive ways, in fact haven't been for years. C is used to implement
operating systems and fundamental parts of many other languages, and is an
invaluable language to know in today's market. C was approved as ANSI
standard on 1989-12-14. it is possible to learn C well in about 2 months,
and it is simple enough to become an expert in about a year. (I have
programmed in C for 15 years.)
C++ tries very hard to be an object-oriented language, but doesn't quite
make it. C++ is an extremely complex language, as evidenced by the draft
ISO standard. the syntax is so complex that common tools to parse and
process programming languages fail to handle C++. the precise meaning of
several of its constructs is still open to debate, and several vendors who
have produced large C++ systems still disagree profoundly on what they
mean. C++ leaves a lot to the implementation for the same reason C does,
but that reason was valid for C. the previous draft standard was rejected
by the international programming language community, as being grossly
inadequate for an international standard. it is unlikely that C++ will
reach standard status for several years, still. even if it does become a
standard, the vendors in the C++ market are not known for their willingness
to follow standards in the first place, and some even make a point of doing
weird things that lock you into their environment. the creator of C++,
quote a Bell Labs proverd that "language design is library design", so you
improve the C++ system to meet your needs by adding new objects and new
functions for them, but you cannot expand on existing objects. it is
possible to learn C++ well in about 18 months, but it takes several years
to become, and constant vigilance to remain, an expert, since the language
is still in flux. (I programmed in C++ for about a year (less than it took
to learn it well, which is why I quit -- life is too long to know C++
well), but still help others understand C++ concepts by relating to other
languages (typically C and Lisp) where the concepts are much better
expressed.)
Common Lisp is object-oriented all the way. the data types in Common Lisp
form a hierarchy, instead of being all distinct. objects are typed, but
variables are not. (in C/C++, all objects are just so many bits, their
meaning depending on how you view them. this is "the hardware way".) this
type hierarchy means that polymorphism and all that fine stuff works for
built-in types. object-orientation in Common Lisp is based in generic
functions that take arguments of any type, and for which methods are
specialized on the types of any number of the arguments. Common Lisp has a
large number of built-in types and operators, but you don't need to know
them all. the difference between a new and an experienced Common Lisp
programmer is not as much in how much of the built-in facilities they use,
but in how the experience programmer builds the language "upwards" to his
problem so it is easier to express himself. this was the real intention
behind object-oriented languages (as expressed in the early papers on
Simula, the first object-oriented programming language), but as long as
only objects and functions can be built by the programmer, not language
constructs, it doesn't really work all that well. Common Lisp is one of
very few languages that allow the programmer to define application-oriented
languages. it is possible to learn Common Lisp well in about a month, but
to master it takes many years and is a constant source of enjoyment to
learn even more elegant ways to do things. (I first met Lisp in 1978 or
so, always returning to its concepts while programming in other languages.
I have programmed in Common Lisp for real for nearly four years, now. I
couldn't earlier, mostly because Common Lisp environments were too
demanding of the hardware I could use, but this has changed, today, it's
C++ and the like that are too demanding for commonly deployed hardware.)
I envy you the opportunity to study Lisp and C and C++ with fresh eyes.
#\Erik
--
I'm no longer young enough to know everything.
Dominique Boucher
John Nagle wrote:
> Prolog is useful for a limited class of problems that are
> expressable in its rule form, and almost useless for anything else.
I do not agree with you. In fact, LOTS of problems are indeed
expressible in rule form. For my master's thesis, I wrote a bytecode
compiler and interpreter for a ML-like language. It did type inference,
and had a very nice syntax error recovery scheme. The source code was
less than 800 lines long, including lexical analysis and syntax
analysis, which accounted for almost half of the size of the program.
So it's not a matter of language expressiveness, but whether you can
translate your ideas and algorithms in that given language. I'm not a
native english speaker. The fact that sometimes I can't find the right
words to express my ideas does not mean that english is not well suited
for expressing them.
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
Espen Vestre
na...@netcom.com (John Nagle) writes:
> Prolog is useful for a limited class of problems that are
> expressable in its rule form, and almost useless for anything else.
With decent (*) Prolog compilers, it's quite useful for a wide variety
of applications.
Espen Vestre
(*) E.g. SICS Prolog on Sun Sparc
Jason Trenouth
On Wed, 2 Apr 1997 03:30:45 GMT, na...@netcom.com (John Nagle) wrote:
> Susan Fisher RSTC Contractor <sfi...@felix.cc.gatech.edu> writes:
> >Gary wrote:
> >> I am looking for a comparison between Prolog and Lisp in terms of
> >> the problem domains of each language.
> >> is there a text on the net? Magazin?
> >> Thanks
>
> >I have a similar question. I am taking an AI course where we may
> >program in any language we choose. I debating the use of C, C++,
> >and LISP. I am looking for any insight on the pros and cons of
> >these languages. I am a very new programmer and have honestly
> >never had the option of which language to use! And advice
> >would be greatly appreciated.
>
> Well, for starters, they're both nearly dead languages, although
> Prolog is deader.
Currently they're both niche languages, but they remain very successful in
those niches. As to which is more popular, that is probably very dependent on
where you work. Prolog is not as popular in the US as it is in, say, Europe.
> Prolog is useful for a limited class of problems that are
> expressable in its rule form, and almost useless for anything else.
> I once wrote a program to configure PC hardware in Prolog; the
> algorithm was suprisingly easy, but the menu system was painful,
> because it needed sequentiality.
I think that Prolog does require slightly more skill to be used effectively,
but I still believe it can be used for general purpose programming quite
adequately.
>
> LISP is sort of like Java, but with more parentheses. Really.
> Both languages have dynamic allocation, garbage collection,
> safety at run time, and the ability to load new code while
> running. Any algorithm you can write in LISP you can probably
> write about equally well in Java. Java is more strongly typed
> than LISP; in Java, typing is mandatory, while in LISP, it's
> optional in the same sense that it's optional in Visual Basic.
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
__Jason
(*) I think there may now be a library for this...
Marco Antoniotti
Whoa! It has been quite a while since we saw a Lisp/Prolog flame :)
Quite refreshing after the usual C/C++ or Java or VB vs. Lisp stuff :)
--
Marco Antoniotti - Resistente Umano
===============================================================================
Neil Matthews
Susan Fisher RSTC Contractor <sfi...@felix.cc.gatech.edu> writes: > Gary wrote:
> >
> > I am looking for a comparison between Prolog and Lisp in terms of
> > the problem domains of each language.
> > is there a text on the net? Magazin?
> > Thanks
>
> I have a similar question. I am taking an AI course where we may
> program in any language we choose. I debating the use of C, C++,
> and LISP. I am looking for any insight on the pros and cons of
> these languages. I am a very new programmer and have honestly
> never had the option of which language to use! And advice
> would be greatly appreciated.
>
It would depend on the application and its proposed method of
implementation. Neither C nor C++ are traditional AI languages,
though if your application represents its data in a very numerical
format (for example, the use of arrays of more than one dimension),
C++ can be rather less messy. LISP is built to accomodate recursive
list operations (it's easier than in C/C++) but personally I found
this to be more of an advantage when dealing with string data. The
drawback with both C and C++ from an AI perspective is that they are
procedural in nature and in that respect defeat the purpose of an
inference-based AI approach. Effectively representing rules and a
knowledge base in C++, whilst not impossible (I've done it), is not
an issue with which you'd want to hamper yourself as a new programmer.
Hope this helps.
Neil Matthews
Nick Wedd
In article <33429E...@amzi.ma.ultranet.com>, reeves
<ree...@amzi.ma.ultranet.com> writes
>> ....Prolog has logic variables and difference lists.
>It's dead, like Latin.
>Ray Reeves
I think Reeves means that he does not use it himself.
Nick
--
Nick Wedd ni...@maproom.demon.co.uk
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.
Rainer Joswig
> [Please, no flames from the LISP fanatics. I've used Franz LISP,
> Interlisp on DEC-10s, Common LISP, and the refrigerator-sized Symbolics.
> It's over. Let it go.]
Well, nowadays you won't need refrigerator-sized
machines. A PowerBook and Macintosh Common Lisp is just fine
(and fast).
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*
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.
reeves
Nick Wedd wrote:
>
> In article <33429E...@amzi.ma.ultranet.com>, reeves
> <ree...@amzi.ma.ultranet.com> writes
>
> >> ....Prolog has logic variables and difference lists.
> >It's dead, like Latin.
> >Ray Reeves
>
> I think Reeves means that he does not use it himself.
>
> Nick
> --
fundamental importance as Latin.
Reeves
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
reeves <ree...@amzi.ma.ultranet.com> writes:
>
> Nick Wedd wrote:
> >
> > In article <33429E...@amzi.ma.ultranet.com>, reeves
> > <ree...@amzi.ma.ultranet.com> writes
> >
> > >> ....Prolog has logic variables and difference lists.
> > >It's dead, like Latin.
> >
> > I think Reeves means that he does not use it himself.
> >
> >No, I mean even if you can find something better it has the same
> fundamental importance as Latin.
Usque tandem NonLisp-codicum-scriptores abutere patientia nostrae? :)
--
Marco Antoniotti - Resistente Umano
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
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
Moribund
Susan Fisher RSTC Contractor <sfi...@felix.cc.gatech.edu> wrote in article
<3341B6...@felix.cc.gatech.edu>...
> I have a similar question. I am taking an AI course where we may
> program in any language we choose. I debating the use of C, C++,
> and LISP. I am looking for any insight on the pros and cons of
> these languages. I am a very new programmer and have honestly
> never had the option of which language to use! And advice
> would be greatly appreciated.
>
<subjective mode on>
While in school, I took this AI class. We could basically write in any
language we knew (assuming of course the profs computer could run the
thing). I know C very well but I'm alittle sketchy on C++ (know just
enough to be dangerous). I decided to use Lisp (figuring what the hell, it
is an AI class after all).
Now, most of my difficulties at first were due to the fact that I didn't
know Lisp well enough in order to express logic. I fixed that (took most
of the time)...but once I got the gist of several things I spent a hard
weekend (about 25 hours) coding a version of an old boardgame called
Broadsides (using Minimax and several other "techniques").
The problem I had (and I alluded to this above) was learning the syntax of
Lisp (when and where I could do things). Once I had a basic understanding
of what was going on I found it *REAL* easy to express myself. I mean
*REALLY* easy... I didn't have to worry about things like memory (garbage
collection), pointers, etc. What I'm basically saying I spent more time
telling the computer what to do and less time telling it how to do it. I
loved it!!!
Now, if only I could find a cheap (< $200) Lisp compiler for the PC...I'd
be in heaven.
<subjective mode off>
Damo
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
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".
David G. Mitchell
In article <3341B6...@felix.cc.gatech.edu>,
Susan Fisher RSTC Contractor <sfi...@felix.cc.gatech.edu> wrote:
>
>I have a similar question. I am taking an AI course where we may
>program in any language we choose. I debating the use of C, C++,
>and LISP. I am looking for any insight on the pros and cons of
>these languages. I am a very new programmer and have honestly
>never had the option of which language to use! And advice
>would be greatly appreciated.
If your course-work involves mainly the kind of programs
typical of such courses -- small planners, natural language
parsers, rule-based expert-system type programs, etc -- then
you should not use C++. Using lisp will save you lots of
time and trouble, and that goes double if you are not an
experienced programmer.
David
PS: Before anyone accuses me lisp religious bias, I use
primarily C and Prolog in my daily work.
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
John Bayko
In article <3341B6...@felix.cc.gatech.edu>,
Susan Fisher RSTC Contractor <sfi...@felix.cc.gatech.edu> wrote:
>
>I have a similar question. I am taking an AI course where we may
>program in any language we choose. I debating the use of C, C++,
>and LISP. I am looking for any insight on the pros and cons of
>these languages. I am a very new programmer and have honestly
>never had the option of which language to use! And advice
>would be greatly appreciated.
I actually wrote an AI project in C, instead of Prolog, because it
was computationally intensive. I spent most of my time doing fiddly
manipulations of pointers and lists, which I wouldn't have had to if
I'd chosen Prolog, or even Lisp (my project was late) - my
recommendation is, unless you have to use it, avoid C for something
like this.
--
John Bayko (Tau).
ba...@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
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
John Atwood
Dominique Boucher <bouc...@iro.umontreal.ca> wrote:
>John Nagle wrote:
>> Prolog is useful for a limited class of problems that are
>> expressable in its rule form, and almost useless for anything else.
>
>I do not agree with you. In fact, LOTS of problems are indeed
>expressible in rule form. For my master's thesis, I wrote a bytecode
>compiler and interpreter for a ML-like language. It did type inference,
>and had a very nice syntax error recovery scheme. The source code was
>less than 800 lines long, including lexical analysis and syntax
>analysis, which accounted for almost half of the size of the program.
Wow, sounds cool; could I take a look at that code?
--
--Office phone: 541-737-5583 (Batcheller 349) home: 757-8772
Office mail: 303 Dearborn Hall, OSU, Corvallis, OR 97331
--I proactively leverage my synergies to grow the business.
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>
Henry Baker
Dominique Boucher <bouc...@iro.umontreal.ca> wrote:
> >The source code was
> >less than 800 lines long, including lexical analysis and syntax
> >analysis, which accounted for almost half of the size of the program.
How many characters wide are your lines? :-) :-)
Arthur A. Gleckler
mar...@infiniti.PATH.Berkeley.EDU (Marco Antoniotti) writes:
> If there where two major developers of Java instead of one and each of
> 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.
In fact, unfortunately, there are several native method interfaces to
Java already. Each of these VMs supports a different native method
interface:
* Sun JDK 1.0
* Sun JDK 1.1
* Microsoft
* Asymetrix Supercede
I believe that Netscape has also proposed an alternate native method
interface.
My understanding is that the JDK 1.0 native method interface is
supported by JDK 1.1 in addition to the new native method interface,
but that support for the 1.0 interface will be dropped in future
versions.
The JDK 1.1 native method interface is more dynamic and flexible than
the 1.0 native method interface, so it's good that innovation didn't
stop. At the same time, this variety of interfaces does make life
difficult.
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
Dominique Boucher
Henry Baker wrote:
> How many characters wide are your lines? :-) :-)
Don't tell everybody you've discoreved the truth! It was supposed to be
a secret ;->
In fact, it's really a toy (small) CAML compiler. It was only an
experiment to see how easy it is to compile a functional language to the
Categorical Abstract Machine. But it works well. The source code can be
found at: ftp://ftp.iro.umontreal.ca/pub/parallele/boucherd/caml.all.pl
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
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 .
Tim Menzies
Gary wrote:
>
> I am looking for a comparison between Prolog and Lisp in terms of
> the problem domains of each language.
> is there a text on the net? Magazin?
> Thanks
> Gary
this isn't quite what you want, but Poole and DeKleer often go
"head to head" in the "my diagnosis engine is better than your
diagnosis engine" stakes. Poole in a Prolog fanatic while DeKleer
is a Lisp man. if language was a key factor in beating the other,
they'd switch in a second. however, it turns out that Prolog vs Lisp
is not the key factor in their friendly rivalry. rather it is the smarts
in their thinking before they sit down to type code.
--
Dr. Tim Menzies rm EE339 |
,-_|\ ti...@cse.unsw.edu.au | Help Wanted: Telepath.
/ \ AI Dept, School of Computer | You know where to
\_,-._* Science& Engineering,Uni NSW | apply.
v Sydney, Australia, 2052 |
+61-2-93854034(p)93855995(f) |
http://www.cse.unsw.edu.au/~timm |
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
>
> 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.
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
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.
--
Royalty free widgets - http://www.undergrad.math.uwaterloo.ca/~j2lynn/java.html
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.
Rainer Joswig
In article <5imvo7$d...@pasilla.bbnplanet.com>, Barry Margolin
<bar...@bbnplanet.com> wrote:
> and then we'll start working on release 2.0."
Which hasn't happened yet.
Sigh.
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?!?
:)
Paul Prescod
In article <hbaker-1004...@10.0.2.1>,
Henry Baker <hba...@netcom.com> 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.
What you are describing is progress: When ANSI C became standardized, the
evolution of the language called "C" slowed, but the evolution of the
user community, vendor community, source code and implementations did not
slow: they abandoned (with some exceptions) the language called C and went
on to various languages that they felt were the natural evolution of C:
Java, C++, Objective-C. So why do you care if something called C has become
the equivalent of Latin, used only when absolute portability and reliably
are required.If Common Lisp dies, it will because something innovative in the
Lisp tradition killed it. Most likely that thing will be written in Common
Lisp, ANSI Scheme or some other well- standardized language and will
thus be portable to all the platforms that implement that standard.
Paul Prescod
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/