Re: Road to Clojure Survey

Rich Hickey wrote:
On Feb 20, 8:24 am, Pascal Costanza <p...@xxxxxxxxx> wrote:
André Thieme wrote:
Scott Burson schrieb:
On Feb 18, 9:21 am, "Mark H." <mark.hoem...@xxxxxxxxx> wrote:
On Feb 9, 11:30 pm, Kenneth Tilton <kentil...@xxxxxxxxx> wrote:
In 25 words or less, why is Clojure better than Common Lisp?
Seqs partake of some of the awesomeness of SERIES, but are easier to
use and more native to functional programming.
One more time, I can't resist... ;-}
http://common-lisp.net/project/fset/
Yes, not bad.
But I doubt someone could use this after having used Clojure.
It misses the nice reader macros.
It does not plug in into CL. For example one has to use image
instead of mapcar.
That's an empty statement. Clojure also doesn't "plug in" into Java.

It's not an empty statement, it's one whose point keeps getting missed/
avoided.

It's a totally empty statement. And I definitely get your point you're trying to make, but you are missing a different point here.

FSet is very nice, but it has to redefine many of the core Lisp
algorithms:

http://common-lisp.net/project/fset/Site/Tinaa-Doc-1.2/fset-package/index.html

Why? Because the core algorithms in the COMMON-LISP package do not
extend to new user-defined types like the ones defined by FSet's
author, and more important, neither do existing algorithms defined in
terms of the CL core. That's what is meant by "It does not plug in
into CL". The analogy is not between Clojure plugging into Java but
between new user-defined data types plugging into Clojure's core
algorithms - they can. So such rewriting of algorithms is not
necessary. Old/core algorithms work with new data structures and new
algorithms work with old data structures.

This is not a small nicety, but a critical feature of a language that
purports to be extensible, IMO.

FSet relates to Common Lisp in exactly the same way as Clojure relates to Java. You decided to use Java as the "back end" for implementing Clojure (or more precisely the JVM, but I will use that interchangeably here in this context), while Scott Burson decided to use Common Lisp as the "back end" for implementing FSet. The only real difference here is that FSet has the advantage that CL macros and functions can be directly used to implement it, while for Clojure you had to implement your own scanner/parser/compiler on top of Java.

Criticizing FSet that algorithms implemented on top of core Common Lisp cannot smoothly be reused with FSet data structures is exactly at the same level as criticizing Clojure that existing Java algorithms cannot smoothly be reused with Clojure data structures. The only reason why you seem to confuse this is that Common Lisp syntax and FSet syntax look (and are) exactly the same, while in the case of Java vs. Clojure, there is a sharp and clear border between implementation language and implemented language.

It's a fundamental problem of language extensions in general: Different language extensions do not compose for free, and there is no remedy against that in the general case. You will get exactly the same problems as soon as people start to build their own language extensions on top of Clojure. Say, one person implements a dataflow extension for Clojure, another implements a logic language for Clojure, then you won't be able to just throw them together and expect to be able to use them in conjunction either. Clojure would be as little to blame in this regard as Common Lisp is to blame that FSet doesn't smoothly work in conjunction with other algorithms and extensions.

Yes, you can prepare for certain extensions to become easier to plug in, and you seem to have done a pretty good job with Clojure for the core collections. But at the same time, you have thrown the baby out with the bathwater - no existing Lisp and Scheme libraries will just work out of the box with Clojure either, a lot of stuff has to be rebuilt from scratch. Again, you had what seems to be good reasons, so I have no gripes with that. But please keep the comparison fair.


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
    ... But I doubt someone could use this after having used Clojure. ... author, and more important, neither do existing algorithms defined in ... FSet relates to Common Lisp in exactly the same way as Clojure relates ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... But I doubt someone could use this after having used Clojure. ... Clojure also doesn't "plug in" into Java. ... Because the core algorithms in the COMMON-LISP package do not ... FSet relates to Common Lisp in exactly the same way as Clojure relates ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... cannot smoothly be reused with FSet data structures is exactly at the ... smoothly be reused with Clojure data structures. ... implemented language. ... You have the choice of treating FSet as the main building block for having flexible collections and ignore all the other collection-like datatypes in Common Lisp. ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... But I doubt someone could use this after having used Clojure. ... author, and more important, neither do existing algorithms defined in ... The analogy is not between Clojure plugging into Java but ... implemented language. ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... But I doubt someone could use this after having used Clojure. ... Clojure also doesn't "plug in" into Java. ... Because the core algorithms in the COMMON-LISP package do not ... That's why I said that "different language extensions do not compose for free, and there is no remedy against that _in the general case_." ...
    (comp.lang.lisp)