Re: Road to Clojure Survey

On Feb 21, 2:50 pm, Pascal Costanza <p...@xxxxxxxxx> wrote:
Rich Hickey wrote:
On Feb 21, 1:16 pm, du...@xxxxxxxxx wrote:
On Feb 21, 6:43 am, Rich Hickey <richhic...@xxxxxxxxx> wrote:

On Feb 21, 6:57 am, Pascal Costanza <p...@xxxxxxxxx> wrote:
Helmut Eller wrote:
* Vend [2009-02-20 22:26+0100] writes:
FSet is a library, not a language.
If I understand correctly, native immutable collections are just one
feature of Clojure, and it integrates well with other features
(polymorphic collection manipulation and concurrency control).
I'm confused by this whole discussion.
Aren't Clojure's collection classes just a library and the Clojure
compiler/language treats them just like any other Java class? Is there
a reason why those classes could not be used in normal Java programs?
They can be used in Java, but you have to adapt your programming style.
Existing Java code will not just automagically work with them in the
general case.
This is FUD - please stop spreading it.
Pascal is not likely to wave his own flag, but I don't think you
realize whom you are talking to. Pascal was a Java programmer long
before he switched to Common Lisp, and his first writings on Common
Lisp (http://p-cos.net/lisp/guide.html) provide some of his
background. However, even if you look up his credentials and are not
impressed, at least realize what you yourself are doing; you are
posting in a Lisp newsgroup arguing with someone who has switched his
major emphasis from Java to Lisp, and so cries of FUD are going to
fall on deaf ears and numb them to other things you have to say.

I do know Pascal. We've met several times and had some great
discussions. I respect both him and his work. I know Pascal's opinions
are well regarded here, all the more reason for them to be accurate. I
too came to Lisp from C++/Java/C#, and greatly value the areas in
which it is superior. But his statement above is simply wrong. It is
not a matter of qualifications or opinion. If you have existing Java
code that takes a collection and does not mutate it you can pass a
Clojure collection and it will work without change or adaptation, i.e.
"automagically".

Two statements have been made, a qualified and an unqualified one. The
unqualified one was "Clojure's collections work seamlessly with Java
code" and the qualified one was "Clojure's collections work seamlessly
with Java code that doesn't mutate them." The first statement is wrong,
the second statement is correct.


Not true. The qualifier wasn't for the seamlessness, but for the
utility.

There is a large body of Java code for which this is
true, and people are leveraging that capability every day.

This may be true, but it doesn't mean that you can afford not to check
whether some arbitrary Java code is compatible with Clojure collections.


Absolutely not. A Clojure collection will work with existing Java code
in precisely the same way as an immutable Java collection, which is
already a legal and possible thing, you can create them, i.e. with
java.util.Collections.unmodifiableList/Map/Set etc. That is, existing
Java code, with whatever policy it has chosen for handling immutable
collections (which has nothing to do with Clojure), will work the same
way, unchanged, with Clojure collections. Other aspects of seamless
that come into play are the lack of copying, lack of adapter or
wrapper classes, direct support for the interfaces, testability via
instanceof, hashCode and equality semantics etc. I think it's seamless
for any reasonable definition of seamless.

Rich
.

Relevant Pages

  • Re: Road to Clojure Survey
    ... I am several orders of magnitude more productive with Lisp than with Java for the kinds of things I am interested in. ... Clojure, or better (if you want to do ... We will now see if functional programming can do better. ... Because Clojure has the same access to all libs that Java also has, ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... native immutable collections are just one ... Aren't Clojure's collection classes just a library and the Clojure ... a reason why those classes could not be used in normal Java programs? ... Existing Java code will not just automagically work with them in the ...
    (comp.lang.lisp)
  • Re: Clojure vs Java speed
    ... vectors in C/C++ and Java. ... The JIT can't, but the coder can. ... You cannot write code that is both that short and that efficient in Clojure. ... You are on the JVM to interoperate with Java. ...
    (comp.programming)
  • Re: Clojure vs Java speed
    ... vectors in C/C++ and Java. ... The JIT can't, but the coder can. ... You can write code that is that efficient in Clojure, and the algorithm can be expressed as compactly, but you may need some support macros. ... inherited from the JVM and there is nothing Clojure can do about it, ...
    (comp.programming)
  • Re: Road to Clojure Survey
    ... I am several orders of magnitude more productive with Lisp than with Java for the kinds of things I am interested in. ... When we ported all our code to Clojure, ... Neither does a profiler for Sun's JVM work with the Kaffe Virtual Machine, ... The first Java core API (and actually also the first public version of the Java language) was implemented in a rush, and some of the bad design decisions in the beginning are still hurting, because of "backwards compatibility" (which is sometimes used as a reason to block progress in some regards -- see genric types and type erasure --, but sometimes ...
    (comp.lang.lisp)