5 ms·

>If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or so

>If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that this is what groovy and kotlin attempt to do. groovy is backwards compatible with java as well, in most cases java code is valid groovy code.

bane 13y ago
I've always been reticent to learn these offshoot dialects of languages unless I really needed to. I'd much prefer it if they were treated as syntax experiments, and good ideas from them filtered back into the main language.
- emp 13y ago
  The problem is the rate things get filtered back to Java. I started using Groovy when I kept waiting and waiting for new language features. In 2003.
  - vorg 13y ago
    Groovy wasn't production-ready in any way, shape, or form until 2005 when the parser was rewritten in Antlr 2, and even then it took years to clean up bugs particularly those related to the MOP which was added in 2006. The Java 5 features weren't even begun to be added to Groovy until early 2006, and they're still buggy. The only significant addition to Groovy since then has been a @CompileStatic tag in Groovy 2.0 in June 2012, which its main user Grails 2.2 didn't dare bundle until 6 months later, but didn't actually use the static compilation. Grails 2.4, still in development, is the first to actually use any of the static features of Groovy, but with a strong caution in the doco: "Care must be taken when deciding to statically compile [Grails] code." http://grails.org/doc/2.4.0.M1/guide/introduction.html#whatsNew24 http://grails.org/doc/2.4.0.M1/guide/introduction.html#whats...
- radiantsand 13y ago
  It's a mistake to think of one "main" language. There's a limit to what can be fed back into the Java language. Other languages like Clojure and Scala have more than enough going for them and stand on their own merits. I'm seeing increasing numbers of teams relegate Java code to legacy status in favor of newer JVM languages.
eropple 13y ago
Groovy isn't attempting to fix Java, it's entirely different. (And it sacrifices type safety--even what of it you get with Java--and performance to do so.)
- mbell 13y ago
  > And it sacrifices type safety Groovy is optionally typed, you can have as much safety as you wish. > and performance to do so If you use static types, you can use @CompileStatic to get most of the performance back.
  - eropple 13y ago
    Optional typing adds a ton of sand to the gears when you actually are writing code. @CompileStatic requires you to spend entirely too long thinking about what's actually legal to annotate and generally sucks rocks to read and write. So, okay, you're technically correct, which is every nerd's favorite kind of correct, but writing it that way sucks. Groovy isn't a bad scripting language (or wouldn't be if discobot ever got done), but it's unserious as a Java competitor where Java is good.
  - vorg 13y ago
    Groovy's main user Grails 2.2 didn't dare bundle Groovy 2's @CompileStatic until 6 months after its release in June 2012, but didn't actually use the static compilation. Grails 2.4, still in development, is the first to actually use any of the static features of Groovy, but has this strong caution in the doco: "Care must be taken when deciding to statically compile code." http://grails.org/doc/2.4.0.M1/guide/introduction.html#whatsNew24 http://grails.org/doc/2.4.0.M1/guide/introduction.html#whats...
lmm 13y ago
I'd say Ceylon is the interesting project here - it keeps the JVM but drops the standard library. (I'm a big fan of Scala - its sheer power is second to none - but it definitely has its ugly parts and many of them can't be fixed as long as it's to remain compatible with the Java standard library)
vorg 13y ago
> groovy is backwards compatible with java as well, in most cases java code is valid groovy code. Whenever I read that meme I get damn suspicious about why java code isn't valid groovy code in all cases. Why only most cases? It all sounds like a recipe for spending half a day debugging simple scenarios where things don't run as intended. To be taken seriously (or as seriously as a language called Groovy can be taken), embrace and extend Java fully, don't embrace only 99% of it before extending. That's what Microsoft tried with J++ and lost a lot of trust with developers that took them a decade to win back.
- netcraft 13y ago
  Its mostly things where the java code contains groovy identifiers, but here is a pretty good list: http://stackoverflow.com/questions/687601/valid-java-code-that-is-not-valid-groovy-code http://stackoverflow.com/questions/687601/valid-java-code-th...

bane 13y ago

I've always been reticent to learn these offshoot dialects of languages unless I really needed to. I'd much prefer it if they were treated as syntax experiments, and good ideas from them filtered back into the main language.

emp 13y ago
The problem is the rate things get filtered back to Java. I started using Groovy when I kept waiting and waiting for new language features. In 2003.
- vorg 13y ago
  Groovy wasn't production-ready in any way, shape, or form until 2005 when the parser was rewritten in Antlr 2, and even then it took years to clean up bugs particularly those related to the MOP which was added in 2006. The Java 5 features weren't even begun to be added to Groovy until early 2006, and they're still buggy. The only significant addition to Groovy since then has been a @CompileStatic tag in Groovy 2.0 in June 2012, which its main user Grails 2.2 didn't dare bundle until 6 months later, but didn't actually use the static compilation. Grails 2.4, still in development, is the first to actually use any of the static features of Groovy, but with a strong caution in the doco: "Care must be taken when deciding to statically compile [Grails] code." http://grails.org/doc/2.4.0.M1/guide/introduction.html#whatsNew24 http://grails.org/doc/2.4.0.M1/guide/introduction.html#whats...
radiantsand 13y ago
It's a mistake to think of one "main" language. There's a limit to what can be fed back into the Java language. Other languages like Clojure and Scala have more than enough going for them and stand on their own merits. I'm seeing increasing numbers of teams relegate Java code to legacy status in favor of newer JVM languages.

eropple 13y ago

Groovy isn't attempting to fix Java, it's entirely different. (And it sacrifices type safety--even what of it you get with Java--and performance to do so.)

mbell 13y ago
> And it sacrifices type safety Groovy is optionally typed, you can have as much safety as you wish. > and performance to do so If you use static types, you can use @CompileStatic to get most of the performance back.
- eropple 13y ago
  Optional typing adds a ton of sand to the gears when you actually are writing code. @CompileStatic requires you to spend entirely too long thinking about what's actually legal to annotate and generally sucks rocks to read and write. So, okay, you're technically correct, which is every nerd's favorite kind of correct, but writing it that way sucks. Groovy isn't a bad scripting language (or wouldn't be if discobot ever got done), but it's unserious as a Java competitor where Java is good.
- vorg 13y ago
  Groovy's main user Grails 2.2 didn't dare bundle Groovy 2's @CompileStatic until 6 months after its release in June 2012, but didn't actually use the static compilation. Grails 2.4, still in development, is the first to actually use any of the static features of Groovy, but has this strong caution in the doco: "Care must be taken when deciding to statically compile code." http://grails.org/doc/2.4.0.M1/guide/introduction.html#whatsNew24 http://grails.org/doc/2.4.0.M1/guide/introduction.html#whats...

lmm 13y ago

I'd say Ceylon is the interesting project here - it keeps the JVM but drops the standard library. (I'm a big fan of Scala - its sheer power is second to none - but it definitely has its ugly parts and many of them can't be fixed as long as it's to remain compatible with the Java standard library)

vorg 13y ago

> groovy is backwards compatible with java as well, in most cases java code is valid groovy code. Whenever I read that meme I get damn suspicious about why java code isn't valid groovy code in all cases. Why only most cases? It all sounds like a recipe for spending half a day debugging simple scenarios where things don't run as intended. To be taken seriously (or as seriously as a language called Groovy can be taken), embrace and extend Java fully, don't embrace only 99% of it before extending. That's what Microsoft tried with J++ and lost a lot of trust with developers that took them a decade to win back.

netcraft 13y ago
Its mostly things where the java code contains groovy identifiers, but here is a pretty good list: http://stackoverflow.com/questions/687601/valid-java-code-that-is-not-valid-groovy-code http://stackoverflow.com/questions/687601/valid-java-code-th...