This is practical information about using Lisp assuming you know about Java.
It would have been useful to me, so I'd like to see if anyone else is
interested. If so please let me know. (This is a first draft.)
http://www.prism.gatech.edu/~gte185y/lisp.html
······@yahoo.com
From: Edi Weitz
Subject: Re: Practical Lisp information page (for Java programmers)
Date:
Message-ID: <87of28ilcn.fsf@bird.agharta.de>
"Rick Giuly" <······@yahoo.com> writes:
> This is practical information about using Lisp assuming you know
> about Java. It would have been useful to me, so I'd like to see if
> anyone else is interested. If so please let me know. (This is a
> first draft.)
>
> http://www.prism.gatech.edu/~gte185y/lisp.html
I don't have any comments on whether this might be practical to Java
programmers but I'd like to ask you to choose your wording more
carefully:
Lisp is interpreted.
Java is compiled.
(Lisp can compile things but I want to ignore that in this document.)
This kind of rehashes old rumors about Lisp that simply aren't
true. In fact, _every_ Common Lisp implementation needs to have a
compiler because that's part of the ANSI standard while there are CL
implementations out there that don't interpret at all (like Corman
Lisp, MCL, SBCL).
I guess what you really wanted to say is that Lisp supports
interactive use while Java doesn't.
Edi.
Edi Weitz wrote:
> "Rick Giuly" <······@yahoo.com> writes:
>
>
>>This is practical information about using Lisp assuming you know
>>about Java. It would have been useful to me, so I'd like to see if
>>anyone else is interested. If so please let me know. (This is a
>>first draft.)
>>
>>http://www.prism.gatech.edu/~gte185y/lisp.html
>
>
> I don't have any comments on whether this might be practical to Java
> programmers but I'd like to ask you to choose your wording more
> carefully:
>
> Lisp is interpreted.
> Java is compiled.
>
> (Lisp can compile things but I want to ignore that in this document.)
>
> This kind of rehashes old rumors about Lisp that simply aren't
> true. In fact, _every_ Common Lisp implementation needs to have a
> compiler because that's part of the ANSI standard while there are CL
> implementations out there that don't interpret at all (like Corman
> Lisp, MCL, SBCL).
>
> I guess what you really wanted to say is that Lisp supports
> interactive use while Java doesn't.
>
> Edi.
Yes, Mr. Giuly, please change this! Some implementations actually
compile every expression you ask it to evaluate at the top level. It's
completely misleading to say that Lisp is interpreted and Java is compiled.
Another error:
(from Giuly's original post) This generates an error because 1 is not a
object, and print-object is for objects only.
(print-object 1 t)
Actually, 1 _is_ an object, and this works fine. Everything in Lisp is
an object, although the compiler may succeed in optimizing the object
boxes away in some circumstances.
On the whole, though, it was interesting to read your document. I've
often explained Java in terms of Lisp, but hearing it from the opposite
point of view was entertainingly disorienting. It needs a bit of
polish; the topics don't hang together that well.
-- Drew McDermott
From: Peter Seibel
Subject: Re: Practical Lisp information page (for Java programmers)
Date:
Message-ID: <m34r402c74.fsf@javamonkey.com>
Edi Weitz <···@agharta.de> writes:
> "Rick Giuly" <······@yahoo.com> writes:
>
> > This is practical information about using Lisp assuming you know
> > about Java. It would have been useful to me, so I'd like to see if
> > anyone else is interested. If so please let me know. (This is a
> > first draft.)
> >
> > http://www.prism.gatech.edu/~gte185y/lisp.html
>
> I don't have any comments on whether this might be practical to Java
> programmers but I'd like to ask you to choose your wording more
> carefully:
>
> Lisp is interpreted.
> Java is compiled.
>
> (Lisp can compile things but I want to ignore that in this document.)
>
> This kind of rehashes old rumors about Lisp that simply aren't true.
> In fact, _every_ Common Lisp implementation needs to have a compiler
> because that's part of the ANSI standard while there are CL
> implementations out there that don't interpret at all (like Corman
> Lisp, MCL, SBCL).
Somewhat along those lines, explaining Lisp function invocation in
terms of Java reflection is not likely to give Java folks the right
impression of what's going on. It is right, to one level of
approximation, but reflection in Java has many connotations that you
probably want to avoid (at least if you are a Lisp advocate). Namely,
it's slow as molasses and awkward to use. And its not quite fair to
Lisp to imply that every function call has to go through all the
overhead involved in looking up a method in Java via reflection and
invoking it--Lisp implementations have been optimized for that case in
a way that Java reflection has not. In most cases, I imagine invoking
a Lisp function is compiled down to something as efficient, if not
more so, than a normal (non-reflective) Java method invocation.
Also, is there a reason you use DEFMETHOD all over the place instead
of DEFUN? While, I guess all your uses of it are legal, you seem to be
implying that DEFMETHOD is the normal way to define new functions.
Which seems like bad form to me, given that you're also creating a
generic function under the covers, etc.
Finally, in the section "Printing Objects", you say:
Lisp has structures, atoms, and lists which I will not consider
objects. I'll refer to all of the non-objects as structures.
Objects are created based on a class. Structures are not.
This is misleading in two ways. One, there's no particular reason to
declare structures, atoms, and lists to not be "objects". I know what
you mean but you're going against standard Lisp terminology here, in
which an object is simply "any Lisp datum". More deeply, you need to
understand why all these other things really *are* objects. That is
they are opaque data types whose nature is determined by the set of
operations that can be performed on them and instance has intrinsic
type and a unique identity.[1]
"Structure" also has an existing meaning in Lisp and you probably
don't want to hijack it to mean something else. That is things created
with DEFSTRUCT (and thus are instances of STRUCTURE-OBJECT) are
structures. Lists, numbers, strings, and all the other objects that
are not instances of either STANDARD-OBJECT, or STRUCTURE-OBJECT are
*not* structures and it probably isn't going to help your readers to
use that term in a non-standard way.
-Peter
[1] Okay, so characters and numbers get a little fuzzy here. But if
you follow the advice that Kent Pitman has given on at least one
occasion and pretend EQ doesn't exist and that EQL is the most
primitive equivalence operator, then characters and numbers happen to
behave just like objects that happen to be automatically interned,
just like symbols. (Note, I said "behave like" not "are". How it's
implemented under the covers can be quite different as EQ exposes.)
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Ed Symanzik
Subject: Re: Practical Lisp information page (for Java programmers)
Date:
Message-ID: <b9qno5$1o1h$1@msunews.cl.msu.edu>
Isn't Java compiled to p-code? It still has to be translated to
machine code by the JavaVM, doesn't it?
From: Michael J. Ferrador
Subject: Re: Practical Lisp information page (for Java programmers)
Date:
Message-ID: <3EC18501.495457A6@orn.com>
Ed Symanzik wrote:
>
> Isn't Java compiled to p-code? It still has to be translated to
> machine code by the JavaVM, doesn't it?
p-code was used in the UCSD p-system. Made hardware by the
pascal micro-engine. My 2nd & 3rd (FORTRAN) langs after BASIC
And Sun has pico-? micro-? -java chips?
And ARM jazelle...
"Rick Giuly" <······@yahoo.com> writes:
> This is practical information about using Lisp assuming you know about Java.
> It would have been useful to me, so I'd like to see if anyone else is
> interested. If so please let me know. (This is a first draft.)
>
> http://www.prism.gatech.edu/~gte185y/lisp.html
I looked over your tutorial and it seems there are some things that
bothered me:
In the defun section you have: "The following example is to
demonstrate to you what Lisp functions would look like in java." I
think you make this section really more complicated than it needs to
be. Maybe you could have said something like:
function(x, y, z) === goes to ===> (function x y z)
So I'm not sure where you are going with the call() example.
Your reflection example is nice, but I don't see how it targets people
who are going from java to common lisp.
You're also alternating between defun and defmethod a lot... I'm not
sure if you feel comfortable choosing between them. If I have to
guess, it seems like you are thinking in java terms, so you are using
'method' when you think 'method' in java. I don't think it is good to
do that when you are translating from java to common lisp. (You seemed
to be doing a 'defmethod main' pretty often.) You'd probably want to
introduce a section on generic methods and how they differ from class
methods. I think translating code directly is sort of similar to
spending your efforts getting a C program to compile under a C++
environment.
If you are interested in learning more about doing OOP in CL, then I
highly recommend "Object-Oriented Programming in Common Lisp: A
Programmer's Guide to CLOS" by Sonya Keene.