JRuby article highlights some possible acceptance issues for Clojure

[AlamedaMike]

This article: http://blog.headius.com/2008/09/elephant.html
by one of JRuby's core developers might be of interest to Clojure-
minded people (CMPs -- a name I'd like to propose for members of our
little niche of the world). He discusses the guff that JRuby has been
getting from the CRuby folks. The situation isn't exactly analagous,
since there is no "C-Clojure", but some of the issues still apply, I
think.

[Rich Hickey]

There are important differences. As you say, there's no C-Clojure. Nor
is there (anymore) a .Net-Clojure.

One of the (many) reasons I didn't implement an existing language is
that doing so pits the ported version against the native version in
irreconcilable ways. To the extent people can write apps in Iron Ruby
and JRuby that won't run on each other, nor on C-Ruby/MRI, how is that
still Ruby?

A ported language will always be dictated to by the 'native' version,
always trail it in features, always struggle with the mapping of those
features to the host VM of the port. And any extensions toward the
host made by the ports are one-way tickets. So, there's an inevitable
tension.

To their credit, the JRuby guys have come up with a great
implementation that at the end of the day may become the fastest, most
powerful, and most acceptable to industry. At that point, it might
make sense to consider it a different language. If Ruby folks are
afraid that JRuby may end up 'winning', well, maybe they will take
away the fact that building a new language on a homemade C-based VM/
interpreter and rolling a whole new set of libraries for everything
from scratch isn't such a great idea anymore.

Languages designed for the JVM (e.g. Clojure/Groovy/Scala) don't have
these issues. As far as Clojure, there is only Clojure on the JVM, so
no incompatibility issues. There is a single story for library
development and extension. One of the reasons I dropped .Net support
was I didn't want bifurcated libraries or duplicated library
development effort. Many of the blog remarks support the industry
acceptance of the JVM.

Another point of the post were complaints that JRuby programmers
weren't writing idiomatic Ruby, but Java-in-Ruby. This is a common
problem for people changing languages - people often complain about
newcomers to Lisp writing C-in-Lisp. That's a lot harder to do in
Clojure, as its functional and non-OO nature keeps you from
replicating the same approaches you might use in Java/Ruby/Python,
even to some extent even imperative Scheme/CL. But that's kind of the
point of Clojure - it's for people who are ready to take a different
approach.

Which leaves the coolness factor.

I dislike writing Java/C# as much as anyone, and Clojure is my ticket
to writing much less of it, while leveraging the efforts of
multitudes. As I've said in my talks, most Clojure users go from "eww,
Java libs" to "ooh, Java libs", leveraging the fact there there is
already a lib for almost anything they need to do. And using the lib
is completely transparent, idiomatic and wrapper free. OTOH, if they
want to customize their interface to a lib, it is trivial to do so in
Clojure.

If, however, the stigma of Java extends to libraries written in it,
even when consumed from languages like JRuby and Clojure, and people
think it's cooler to reinvent than reuse, they need a new definition
of cool. Perhaps only open-source is cool, and Java, not having been
open source all along, is representative of "the other side". But it's
open source now, and there have always been a huge number of open
source Java libraries. That's not to mention the very large pieces of
open source JVM-based infrastructure - servers, not merely libs -
things like Tomcat, Terracotta, OpenMQ, JavaDB etc. So while Java-the-
language may be boring, old, and uncool, the JVM platform is an
incredibly productive place for a language to be.

Getting things done is cool.

Rich

[Chouser]

On Sat, Sep 6, 2008 at 2:36 PM, Rich Hickey <richh...@gmail.com> wrote:
>
> There are important differences. As you say, there's no C-Clojure. Nor
> is there (anymore) a .Net-Clojure.

There may one day be a Clojure-for-JavaScript (ClojureScript?), which
of course will suffer from just such problems. Is that a good enough
reason to resist the creation of ClojureScript?

> Which leaves the coolness factor.
>
> I dislike writing Java/C# as much as anyone, and Clojure is my ticket
> to writing much less of it, while leveraging the efforts of
> multitudes. As I've said in my talks, most Clojure users go from "eww,
> Java libs" to "ooh, Java libs"

Following a Java lib's documented example, but getting it done in half
as many lines of Clojure is cool. Lisp is cool. Having a language
that's like lisp and has access to all of Java, but has more libs than
lisp and that's more dynamic than java is *way* cool.

--Chouser

[Rich Hickey]

On Sep 6, 5:11 pm, Chouser <chou...@gmail.com> wrote:

> On Sat, Sep 6, 2008 at 2:36 PM, Rich Hickey <richhic...@gmail.com> wrote:
>
> > There are important differences. As you say, there's no C-Clojure. Nor
> > is there (anymore) a .Net-Clojure.
>
> There may one day be a Clojure-for-JavaScript (ClojureScript?), which
> of course will suffer from just such problems. Is that a good enough
> reason to resist the creation of ClojureScript?
>

I don't think so. Any such script version is likely to be a component
of a larger Clojure app. I imagine a ClojureScript will be a subset of
Clojure + some context-specific capabilities, and thus complementary.

Rich

[AlamedaMike]

> Lisp is cool.  Having a language
> that's like lisp and has access to all of Java, but has more libs than
> lisp and that's more dynamic than java is *way* cool.
>
> --Chouser

To which I can only add: And having a language that also handles side-
effects and thread interaction well is *extremely* cool.

[AlamedaMike]

> Getting things done is cool.

Yup. I've been programming for 30+ years and I've gotten too old and
too cranky to tolerate a lot of bullsh*t, high ceremony, and wheel
reinvention.

I had high hopes for Paul Graham's Arc, but his goals are more
rarified. So despite my great respect for his ideas, that is not going
to work for me anytime soon. Giving up continuations to get a zillion
libraries and tools is the right choice for anyone who needs to do
real work. I've spent a good part of the last 18 months looking at
different languages to find the cleanest and most productive one. I do
believe I've found it. Well done and thank you, sir!

[AlamedaMike]

> Getting things done is cool.

One other point. Getting things done in Clojure and getting paid for
it is cool. One of the things I like about clojure is that its easy
interface to java dramatically increases its chances of industry
acceptance. New technologies, to be accepted, must solve a FELT crisis-
level problem while not creating significant new problems.

Context: the JVM is great, has vast acceptance and many tools,
libraries, and developers. Many existing apps are written in it and
need to be maintained. Industry will be using it for a long time,
especially if they have a solution to the threading problem.

Crisis: Java is the pits. Programmers have never really liked it. With
the recent rise of dynamic languages they are increasingly clear why
they don't like it. Paul Graham's writings have lit the fires for Lisp-
class languages, increasing the felt frustration. Mutli-core chips are
now the norm and few languages can exploit them. Demand for
development resources in industry still exceeds supply. Lots of felt
frustration and experimentation in the air.

Solution (first try): Jython and JRuby don't solve the thread
interaction and side-effect problems well. They are also rather slow
and don't have macros. But their standard versions are well known,
especially in the case of Python. Erlang and Haskell don't run on the
JVM. Lisp-class languages that do run on the JVM (Kawa, etc.) are
nice, but are more tainted by the market perception problems of Lisp
and Scheme.

Solution: It must be JVM-based and it must be a Lisp-class language to
get the full power of macros and s-expressions. Clean up the worst of
the innumerable parens. Add the map and array structures with literal
support which have proven so useful in Python (which cleans up still
more parens). Make it reasonably fast. Make java interaction trivial.
Reduce bugs dramatically and enable powerful threading by controlling
side-effects.

I really do think you've got a tiger by the tail here, Rich. Now all
we have to do is spread the good news to the huddled masses yearning
to breathe free. I'd love to see some more discussion on this forum on
how we can conquer the programming world with this. One possible point
of attack is to try to interest Paul Graham in writing about Clojure.
That by itself would drive a lot of interest here. He's pushing Arc,
of course, but he might still be willing to discuss it.