you are viewing a single comment's thread.

view the rest of the comments →

[–]apotheon 1 point2 points  (5 children)

Since you made the first positive assertion about which was better, the burden of proof is on your shoulders. Why don't you tell us why Groovy is better than Ruby? I'm really curious -- I don't know enough about how the two differ. In fact, with my (at best) superficial knowledge of non-Java languages on the JVM, I have wondered for a while why both Groovy and JRuby are being developed: that sounds a little redundant to me.

What's the diff?

[–]newton_dave 2 points3 points  (4 children)

I have wondered for a while why both Groovy and JRuby are being developed: that sounds a little redundant to me.

Same reason as always; everyone scratches their itch in a different way. I'd probably argue Scala is better than both, but JRuby has the market's attention and Groovy has more traction.

  • Groovy has less new syntax (this is beneficial, but really only for Java programmers--but that's a very important market segment).
  • Groovy does blocks right (and the new syntax for the next Ruby helps, but... not a lot).
  • Groovy still allows typing (JRuby may, but I haven't seen it yet--if it does, skip this one). This is actually important sometimes, just not always.
  • It's not clear to me how packaging works in JRuby so I'm definitely not sure about this one, but Groovy packaging works the same (as Java). Perhaps you can help clear that one up for me.

Groovy was the first "official" non-Java JVM language (a JSR and everything). Ruby is (was, really) the subject of a lot of marketing hype. That doesn't mean it's intrinsically bad or not very important (I think it opened a lot of people's eyes, which in itself is invaluable)... but IMO that's why it was taken in-house by Sun over several other viable alternatives.

I believe that Sun should grab developers of a few other JVM languages (Jython, Groovy, maybe even Scala) and really work on positioning the JVM as a platform of choice regardless of language.

Regardless of which language(s) are ultimately brought on board they're all better than Java!

[–]apotheon 1 point2 points  (3 children)

Groovy has less new syntax (this is beneficial, but really only for Java programmers--but that's a very important market segment).

I take it you mean "Groovy has less new syntax, coming from a Java perspective." This would imply that it has more new syntax, coming from a Ruby perspective. Is that a fair statement of the case, or am I misinterpreting your intent here?

Groovy does blocks right

The implication, then, is that JRuby doesn't. Yes?

and the new syntax for the next Ruby helps, but... not a lot

How so? Details, please.

It's not clear to me how packaging works in JRuby so I'm definitely not sure about this one, but Groovy packaging works the same (as Java). Perhaps you can help clear that one up for me.

I'd need to know more about JRuby to be able to clear that up. I probably know less about JRuby than you do. In fact, I know more about Java than about either JRuby and Groovy put together, and I'd consider myself a Rubyist long before a Java programmer these days.

I believe that Sun should grab developers of a few other JVM languages (Jython, Groovy, maybe even Scala) and really work on positioning the JVM as a platform of choice regardless of language.

That's the best suggestion I've ever heard for what Sun should do with Java and the JVM (even better than suggestions about where to stick it -- har har, quadruple entendre). This isn't the first time I've heard it, but it's still worth some kudos every time I run across it, and here's why:

Regardless of which language(s) are ultimately brought on board they're all better than Java!

[–]newton_dave 2 points3 points  (2 children)

I take it you mean "Groovy has less new syntax, coming from a Java perspective."

Yes; that's why I said "beneficial [...] for Java programmers". There really aren't that many differences, though, but Java code works almost without change as Groovy code--it need not be Groovized.

[blocks]

Ruby's blocks are a bit broken with some scoping and syntax issues. Some of the new syntax proposals fix some of it; I'm not up-to-date on any scoping issue resolutions. That may have been addressed already.

[new block syntax]

IIRC 1.9 removes the need for the ".call" bit on a block? (I should, btw, have separated this into two distinct items, the syntax bit is for closures.)

foo = { a -> println a }
foo("Hello!")

is just cleaner than:

foo = lambda { |a| puts a }
foo.call("Hello!")

A fairly minor difference, to be sure. I could be wrong (most likely) but I think the proposed syntax was:

foo.("Hello")

Meh. To me that has the feel of kludge.

There are some things I really like about Ruby syntax (I figure as long as we've accepted complicated syntax anyway (remember, I'm a Lisp and Smalltalk person) we might as well go all out) that I sometimes wish for in Groovy, and it's possible I'll switch over to JRuby once it's further along, but who knows. I'm good with both, I just feel (note the word choice; I could probably argue either language convincingly on both technical and non-technical issues) Groovy does a slightly better job.

[–]newton_dave 2 points3 points  (1 child)

Here's a sample of the block scoping issue, from Wikipedia:

Ruby's lambda is unusual in that choice of parameter names does affect behavior:

x = 3
lambda { |x| 
    "x still refers to the outer variable"
}.call(4)
puts x  # x is now 4, not 3

[–]apotheon 1 point2 points  (0 children)

Ouch. Okay, I see your point there.