Subject: Re: Java vs lisp (was: Re: Prolog vs. Lisp)
From: Erik Naggum <>
Date: 1997/04/04
Message-ID: <>

* 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

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

I'm no longer young enough to know everything.