I'm not trying to start a language war, especially since Clojure is
trying to
be both a Java and a Lisp. This is more of a user experience report.
I'd be more interested in hearing about your experiences and where you
find an impedance mismatch than having a Lisp vs Java discussion.
Where do you struggle, not which is better.
I am trying to understand why lisp is more productive (for me) than java.
I am also trying to understand whether Clojure is closer to lisp (e.g.
faster for me)
or java (e.g. slower for me).
Maybe you don't feel the mismatch or you are equally productive in both.
Your OODA-loop times [1] may vary.
Televisions vs Monitors.....
I'm trying to port some Java code to Clojure and I'm running into an
interesting "snag".
In Clojure it is possible to add type hints and I thought this might be
a good idea.
I no longer believe it is. I've also gotten some insight about why I
find my "OODA loop"
in lisp is so much faster than it is in Java.
It comes down to types.
In Java, types are associated with the boxes, so you have a box and you
give it a
label, say "Television". Only a television can go in that box.
In Lisp, types are associated with the thing itself, so a television is
always a
"Television". You can put it in any box.
Now I find that I want to change a television (old school) and make it
into a
monitor screen (new school). In Lisp, I just change the object and
everything
"just works". My OODA loop is measured in seconds.
In Java I find that I have to make systemic changes to multiple
files because I pass around the Television-boxes and I can't put monitors
in Television boxes (they are not IS-A so inheritance fails, the
exceptions they
throw are different, the method signatures are different, etc). If
Television
is a widely used thing then I end up changing lots of little files. My OODA
loop is around 10 minutes or more for a change like this.
I would have thought that the work necessary to make a change from a
television to a monitor would be the same in either case but it is not. Most
of the things I do to a television (plug it in, turn it on, move it,
etc) are not
specific to Television and the lisp routines are agnositc. The Java routines
are tightly signatured.
In theory, IF the Java code were structured properly then it would be just
as easy to change a Television into a Monitor but who knew that anyone
would replace their Television with some strange device?
I will be interested to see if Clojure comes down on the side of Lisp
in this, or if Java types bleed over in non-lispish ways.
NULL, EMPTY LIST, BOOLEANS, oh my!
Another hint of this impedance mismatch is the whole discussion of
boxed vs unboxed booleans.
One thing that lisp got absolutely right is the unification of the symbol
nil, the empty list (), and the boolean "false". Clojure seems to have
waffled on this point and I think it will cause grief in subtle places.
In Java I find it makes me insane to try to use an iterator over a
declared collection and have it fail due to null. For instance,
Set<GraphNode> nodes = null;
(insert lots of code/classes/files)
for (GraphNode n : nodes) { ....}
fails! So I have to protect the for with
if (nodes != null) {
for (GraphNode n : nodes) {...}
}
In other words, the 'for' iterator construct does not know that 'null'
is a valid value for 'nodes' even though 'null' is a valid value for
anything.
The Java "solution" to this, proposed by a coworker, is to create a
GraphNodeFactory which properly initializes all substructures. That's
a great idea but deeply changes the existing design. The substructures
are dynamically discovered so GraphNodeFactory would not know them.
I understand why Clojure did not do the classic lisp unification but
tries to keep the Java "false" boolean idea around but I find that it
makes coding somewhat more tedious.
In Clojure, nil does not map to false in some cases and it always
comes as a surprise to me. I know that Scheme broke the unification,
which always surprises me and why I don't code in Scheme. I'm trying
to give Clojure the benefit of the doubt.
Tim Daly
[1] http://en.wikipedia.org/wiki/OODA_loop
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
