3 ms·

Java continues to evolve to a bad Groovy.

by AtlasBarfed 3y ago

bheadmaster 3y ago
Groovy itself is a bad Groovy.
- AtlasBarfed 3y ago
  bad opinion is bad I get gradle is a disaster (but that's more of a poorly managed and evolved DSL problem) But ... does anyone use Spock and think "groovy sucks"? Yeah, I doubt it.
  - svieira 3y ago
    I hate to be "that guy" but ... raises hand. Spock is also a DSL disaster that's trying to be ScalaTest (https://www.scalatest.org/user_guide/property_based_testing https://www.scalatest.org/user_guide/property_based_testing) but in a dynamic language. Every time I use it I have to re-learn the syntax. (I have the same issue with Gradle, so maybe it's just-me?)
    - bombcar 3y ago
      My problem with gradle is I never use it enough to get familiar with it, once the problem is solved I promptly forget everything.
      - AtlasBarfed 3y ago
        It's the perfect example of a bad DSL. A "DSL" like SQL that you use hundreds of times a year you'll learn the model of. A DSL like groovy that you use once for project setup (and for that you'll one-off it likely and stackoverflow the rest of the question) is not. And it isn't really natural, it's a bunch of arcane steps that at the end might superficially look a bit consistent, but still really isn't. Groovy really needs an autocompleter or a generator. Or, well, as you say, you stackoverflow for everything outside the very vanilla basics of it. But good luck getting the right version match to the syntax you need. Christ.
        ackfoobar 3y ago
        Having types in Gradle by using the Kotlin DSL, with IntelliJ auto-complete, solves ~80% of that pain.
  - adl 3y ago
    Raises hand Here! I have to work with Spock on a Java codebase and I think groovy sucks ;-)
  - photogineer 3y ago
    Yeah I use Spock and Groovy all the time, good god does it suck big ones.
ulrikrasmussen 3y ago
How so? I don't think there are many good things to say about Groovy, but I generally agree with most new features introduced to Java. What do you think Groovy does better?
- AtlasBarfed 3y ago
  - String interpolation - triple-quote strings / blocks - minimal class boilerplate (this posting) - closures (Java closures are worse IMO) - usable hashbang for UNIX - I think java has strings in switch now, don't they? Do they have expressions? WAIT, does Java STILL force you to write getter/setters?
  - jimbokun 3y ago
    A form of string interpolation is in this release.
  - mbfg 3y ago
    features that make strings easier to use are bad in my opinion. the number one problem in java is people circumventing the type system with strings. switch on strings is there, as are switch expressions. records now removes the need for getters in immutable contexts.
  - neonsunset 3y ago
    Hashbang aside this is a solid description of a base feature set of C# :D
  - marginalia_nu 3y ago
    But Java has all those features...?
    - AtlasBarfed 3y ago
      Oops, sorry those are features java "stole" from groovy. Java has the nullsafe operator now and the elvis too, doesn't it? I don't use the spaceship operator much, implicit sorting works pretty well. Groovy's closures have a lot less GOTCHAs. They simply work as expected, at least to me. Half the time I use java closures and I get complaints in compilation that I don't get in Groovy, but maybe they've improved closures more. Groovy's GPars library is the bomb for concurrency/parallelism. I don't know if I could function in normal java constructs. The .with keyword is a sneaky useful technique where you can declare a piece of data like: "some cli command" .with { it.execute} .with { /* parse output */ } It allows chained calls that flow naturally. Groovy generally allows pretty compact flowed calls which makes scripts a lot easier. Groovy scripting with implicit vars is a lot easier than any java scripting, even with the "simplification" described. The shorthand access/navigation of nested lists and maps, and the map / list literals (also taken by java at some point I think) are really nice to have. Also a + operator for lists and maps I use a lot Groovy's ability to generically call methods without mucking through 10 lines of reflection is sometimes nice. The auto-gen of getter/setters is a must have, I think Kotlin has those too? CompileStatic lets me selectively use full java speed without groovy overhead. In general, I like Groovy because it is typing-optional. Python and Javascript suck because they don't really have optional type enforcement. Java sometimes asks for too much typing. Groovy lets me select as needed. The actual sane = for string assignment and == for sane string comparison is nice. But honestly, Java with the listed features is a lot better. I'll probably still use groovy for doing what would normally done with bash (UGH) since I have a big CLI/scripting library base that handles argument parsing, json, encode/decode, encrypt/decrypt, zip/unzip, in nice compact syntax. Groovy is basically a dead language now anyway. The world is overrun by JavaScript and Python, and AI looms to replace us all with horrid AI python or javascript glue code.

Java continues to evolve to a bad Groovy.

bheadmaster 3y ago

Groovy itself is a bad Groovy.

AtlasBarfed 3y ago
bad opinion is bad I get gradle is a disaster (but that's more of a poorly managed and evolved DSL problem) But ... does anyone use Spock and think "groovy sucks"? Yeah, I doubt it.
- svieira 3y ago
  I hate to be "that guy" but ... raises hand. Spock is also a DSL disaster that's trying to be ScalaTest (https://www.scalatest.org/user_guide/property_based_testing https://www.scalatest.org/user_guide/property_based_testing) but in a dynamic language. Every time I use it I have to re-learn the syntax. (I have the same issue with Gradle, so maybe it's just-me?)
  - bombcar 3y ago
    My problem with gradle is I never use it enough to get familiar with it, once the problem is solved I promptly forget everything.
    - AtlasBarfed 3y ago
      It's the perfect example of a bad DSL. A "DSL" like SQL that you use hundreds of times a year you'll learn the model of. A DSL like groovy that you use once for project setup (and for that you'll one-off it likely and stackoverflow the rest of the question) is not. And it isn't really natural, it's a bunch of arcane steps that at the end might superficially look a bit consistent, but still really isn't. Groovy really needs an autocompleter or a generator. Or, well, as you say, you stackoverflow for everything outside the very vanilla basics of it. But good luck getting the right version match to the syntax you need. Christ.
      - ackfoobar 3y ago
        Having types in Gradle by using the Kotlin DSL, with IntelliJ auto-complete, solves ~80% of that pain.
- adl 3y ago
  Raises hand Here! I have to work with Spock on a Java codebase and I think groovy sucks ;-)
- photogineer 3y ago
  Yeah I use Spock and Groovy all the time, good god does it suck big ones.

ulrikrasmussen 3y ago

How so? I don't think there are many good things to say about Groovy, but I generally agree with most new features introduced to Java. What do you think Groovy does better?

AtlasBarfed 3y ago
- String interpolation - triple-quote strings / blocks - minimal class boilerplate (this posting) - closures (Java closures are worse IMO) - usable hashbang for UNIX - I think java has strings in switch now, don't they? Do they have expressions? WAIT, does Java STILL force you to write getter/setters?
- jimbokun 3y ago
  A form of string interpolation is in this release.
- mbfg 3y ago
  features that make strings easier to use are bad in my opinion. the number one problem in java is people circumventing the type system with strings. switch on strings is there, as are switch expressions. records now removes the need for getters in immutable contexts.
- neonsunset 3y ago
  Hashbang aside this is a solid description of a base feature set of C# :D
- marginalia_nu 3y ago
  But Java has all those features...?
  - AtlasBarfed 3y ago
    Oops, sorry those are features java "stole" from groovy. Java has the nullsafe operator now and the elvis too, doesn't it? I don't use the spaceship operator much, implicit sorting works pretty well. Groovy's closures have a lot less GOTCHAs. They simply work as expected, at least to me. Half the time I use java closures and I get complaints in compilation that I don't get in Groovy, but maybe they've improved closures more. Groovy's GPars library is the bomb for concurrency/parallelism. I don't know if I could function in normal java constructs. The .with keyword is a sneaky useful technique where you can declare a piece of data like: "some cli command" .with { it.execute} .with { /* parse output */ } It allows chained calls that flow naturally. Groovy generally allows pretty compact flowed calls which makes scripts a lot easier. Groovy scripting with implicit vars is a lot easier than any java scripting, even with the "simplification" described. The shorthand access/navigation of nested lists and maps, and the map / list literals (also taken by java at some point I think) are really nice to have. Also a + operator for lists and maps I use a lot Groovy's ability to generically call methods without mucking through 10 lines of reflection is sometimes nice. The auto-gen of getter/setters is a must have, I think Kotlin has those too? CompileStatic lets me selectively use full java speed without groovy overhead. In general, I like Groovy because it is typing-optional. Python and Javascript suck because they don't really have optional type enforcement. Java sometimes asks for too much typing. Groovy lets me select as needed. The actual sane = for string assignment and == for sane string comparison is nice. But honestly, Java with the listed features is a lot better. I'll probably still use groovy for doing what would normally done with bash (UGH) since I have a big CLI/scripting library base that handles argument parsing, json, encode/decode, encrypt/decrypt, zip/unzip, in nice compact syntax. Groovy is basically a dead language now anyway. The world is overrun by JavaScript and Python, and AI looms to replace us all with horrid AI python or javascript glue code.