Prolog vs. Lisp

1783 views
Skip to first unread message

Gary

unread,
Apr 1, 1997, 3:00:00 AM4/1/97
to

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

unread,
Apr 1, 1997, 3:00:00 AM4/1/97
to

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

* 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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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
> > Gary

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

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

unread,
Apr 2, 1997, 3:00:00 AM4/2/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

In article <nagleE7...@netcom.com>, na...@netcom.com (John Nagle) wrote:

> [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).

--
http://www.lavielle.com/~joswig/

Erik Naggum

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

* 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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to Fergus Henderson

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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
> --
>No, I mean even if you can find something better it has the same
fundamental importance as Latin.
Reeves

Brian N. Miller

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

* 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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to


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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

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

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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.

--
http://www.lavielle.com/~joswig/

Rob Mayoff

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

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

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

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

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

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

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

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

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

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

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

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

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

* 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

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

* 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, yo