Re: Road to Clojure Survey

On 20 Feb, 21:43, Pascal Costanza <p...@xxxxxxxxx> wrote:
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/i...

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.

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

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. ... Because the core algorithms in the COMMON-LISP package do not ... You decided to use Java as the "back end" for implementing Clojure, while Scott Burson decided to use Common Lisp as the "back end" for implementing FSet. ...
    (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
    ... FSet is very nice, but it has to redefine many of the core Lisp ... Because the core algorithms in the COMMON-LISP package do not ... AFAIR, the main virtues of Clojure, that you've advertised, are ...
    (comp.lang.lisp)
  • Re: question about Clojure immutable structures
    ... We also have examples of how Common Lisp can ... if Clojure could be extended towards CL ... That already is a working CL for the JVM. ... So, from ABCL you can use Clojures persistant datastructures, the STM, ...
    (comp.lang.lisp)