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.

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

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.