Re: Road to Clojure Survey

On Feb 21, 4:53 pm, Pascal Costanza <p...@xxxxxxxxx> wrote:
Rich Hickey wrote:
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.

I made the qualified statement. I guess I know better what the qualifier
was for.

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.

Do I speak Spanish, or what?!?


We are talking about this (English) statement of yours:

"Existing Java code will not just automagically work with them in the
general case."

To which I replied (and you've elided, and ignored):

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

Your example has nothing to do with the issue ("existing Java code").
It is an inane example of someone writing new code creating an
immutable collection and trying to add something to it.

I'm done - the last word is yours.

Rich

import clojure.lang.*;
import java.util.*;

public class Test {

public static void main(String[] args) {
Cons cons = new Cons(1, new Cons(2, new Cons(3, null)));
Collections.addAll(cons,4);
System.out.println(cons);
}

}

java -classpath clojure.jar Test
Exception in thread "main" java.lang.UnsupportedOperationException
at clojure.lang.ASeq.add(ASeq.java:109)
at java.util.Collections.addAll(Collections.java:3515)
at Test.main(Test.java:8)

Pascal

--
ELS'09:http://www.european-lisp-symposium.org/
My website:http://p-cos.net
Common Lisp Document Repository:http://cdr.eurolisp.org
Closer to MOP & ContextL:http://common-lisp.net/project/closer/

.

Relevant Pages

  • Re: Road to Clojure Survey
    ... 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 ... not a matter of qualifications or opinion. ...
    (comp.lang.lisp)
  • 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: 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)