[racket] Off-topic: Scheme for JVM?

On Wed, Jun 9, 2010 at 1:07 PM, Thomas Chust <chust at web.de> wrote:
> I would not recommend Clojure, although it has some fancy features and
> is currently en vogue, because the standard library seems to be in a
> very bad shape and full of bugs.

I completely disagree with this.  I have found Clojure to be extremely
stable, and the standard library to be well-organized and relatively
bug-free.  Even the bleeding edge builds are surprisingly stable,
although you're certainly more likely to encounter problems than if
you use one of the official releases.  I wouldn't hesitate to
recommend Clojure to anyone who likes Scheme/Lisp/Racket but requires
interoperability with Java -- it was designed from the ground up with
interoperability in mind.

Clojure is definitely a new Lisp dialect, and is not exactly the same
as Scheme.  Many of the changes are, in my opinion, improvements.  The
built-in datatypes (e.g., the persistent vectors and hash maps) are a
joy to use, and are elegantly layered into interfaces that allow them
to be manipulated polymorphically.  For example, you can manipulate
vectors with sequence functions (first, rest, etc.), associative data
structure functions (assoc, get, etc.), as well as vector-specific
functions, and you can even use a vector as a function of its indices.
 Racket's sequence and collection types feel clunky in comparison, and
other Schemes are even worse.

Of course, Clojure makes compromises to exist on the JVM -- no complex
numbers, no continuations, no tail-call optimization (although it
offers a few workarounds).  Furthermore, the Racket ecosystem (e.g.,
Typed Racket, Scribble, etc.) has a rather large number of
extraordinary features that Clojure doesn't even attempt to address.
So if you're expecting a clone of Racket that can work on the JVM,
you'll be disappointed.  But what Clojure does, it does rather well,
and I can say without reservation that Clojure is a rather pleasant
way to get real work done on the JVM using a Scheme-like functional
programming approach.