Re: Sun begins to fund JVM scripting languages

--- Jochen Theodorou <blackdrag@...> wrote:
snip
> I see also negative effects for groovy, because
> which company should
> support Beanshell or Groovy now, when Sun is putting
> their attention on
> JRuby...

Personally, from the perspective of a tech lead on
business app, I think all of the attention on being
directed at alternatives to Java on the JVM will only
help all of the languages in being adopted. It
legitimitizes (is that word?) the practice of running
other languages on top of the JVM, making it an easier
sell.

>Or to say it different... what should I
> answer a CEO when I am
> asking for financial support, when he asks me why he
> should support
> Groovy, when Sun does support JRuby? I really don't
> know what I should
> say here :(
>
> bye blackdrag

The conciseness, readability, peformance, etc... of
BeanShell, JRuby, Ruby, and Groovy are not identical.
All things being equal, Sun suppport of JRuby might
make a difference. But in real world project, things
are never equal. At least for my project, comparing
languages side by side with real application spoke
volumes. We read code much more often that we write
it. To my eye, Groovy easily stood out as the *best*
code noise reducer.

For example, the last time I looked (and believe me, I
looked!), you still had to *explicitly* declare
numbers to be BigDecimal in JRuby/Ruby/Python/Jython.
This is problematic. I attended an EJB3 demo where the
examples were defining money as floats or doubles. I
can't think of a single *business* property where it's
ok to use float or double.

Another simple example, constructors. I don't bother
with them in Groovy - at all. Even though parameters
may be optional in Ruby, the fact that I don't have
specify in the class in advance what properties I
might want to initialize when I create a new object is
huge. In the abstract, it doesn't sound like much. In
practice, it makes a big difference.

It's politically correct for those involved with the
project not flame other languages. But that doesn't
mean that there aren't important differences that show
up in non-trivial application code. For me, in
practice with a large code base, its the sum of these
differences that make Groovy stand out.

Having been a speaker and an attendee at various
Groovy presentations, I believe there are three things
that are necessary for broader Groovy adoption and
they have nothing to do with Sun:

1. finish Release 1.0
2. comprehensive docs
3. implement code complete in the IDE plugins



Scott

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email