5 ms·

> Gradle is by far the worst-designed technology I've encountered in ~30 years of programming. I nominate Groovy. Many of gradle's failures are just idiomatic

by usrusr 6y ago

> Gradle is by far the worst-designed technology I've encountered in ~30 years of programming. I nominate Groovy. Many of gradle's failures are just idiomatic groovy. The entire mindset of "friendly simplifications" that work 80% of the time, and if they give pretend that you don't notice, look, there's pretty code over there! Even kotlin suffers from some of that (you can override a val x:Int with a val x:Int get() unless it's tied down otherwise, talk about principle of maximum surprise) but the genes from the other parent avoid the worst.

rcoveson 6y ago
Can anybody explain to me why it ever seemed like a good idea to make both: (1) Semicolons at the ends of lines and (2) Function-call parentheses, not required, and not illegal, but optional? It strikes me as an abdication of the responsibility of a designer, like making both String::substring and String::substr available as aliases one to the other. Who cares? Choose one and stick with it! Otherwise it becomes a race between linter-writers and community programmers to see if the entire ecosystem will become polluted with an ugly mix of both styles. A race which the linter-writers always lose.
- zmmmmm 6y ago
  Groovy was created during the time when Ruby was taking off and was dramatically improving productivity of creating basic CRUD type web sites. So Ruby had a beautiful simple syntax, and I think Groovy was an experiment to see how close you could get to that while maintaining compatibility with Java syntax. It's actually a remarkable success as far as it goes - most Java code can be copy and pasted in and is valid Groovy. But of course it only works because it optionally accepts parentheses, explicit vs implicit arguments etc. It does lead though to one of the biggest lies which is "if you know Java then you already know Groovy!" - that's just a mean trick to play on people.
  - oblio 6y ago
    And to make things more interesting at some point the nearly-frozen-in-time Java started evolving again so Groovy is stuck in some sort of parallel universe because Ruby failed to get mass traction and most people are not familiar with it while Java 8+ has its own concepts that don't translate as neatly as Java 6-7 concepts translated to Groovy at the time.
  - rcoveson 6y ago
    Maybe the rest of Ruby is more "beautiful" and "simple", but those adjectives don't apply to the inconsistency caused by optional code punctuation. I think Ruby users even realized this, and have since imposed strict requirements on their projects that only one style be followed. Groovy is all the more guilty for carrying the bad tradition forward. It's akin to somebody looking at the success of C and deciding that its macro system must be perfectly preserved going forward.
    - dragonwriter 6y ago
      > I think Ruby users even realized this, and have since imposed strict requirements on their projects that only one style be followed. A common set of conventions in the Ruby community uses both options for optional punctiation, with context controlling which is used for a particular case. E.g., 1. Use a single expression per line, and don't combine the line starting or ending a block with the contents, and don't use semicolons where they are unnecessary (so, semicolons are used only to separate the opening and “end” of single-line blocks.) 2. Use parens among function calls, except omit them in calls that are part of internal DSLs.
- usrusr 6y ago
  For Groovy the simple answer is they claimed that every piece of Java code would also work in Groovy. This wasn't ever true (well, maybe before someone decided that the equals() method is confusing), but it didn't matter, because of the "80% is plenty" mindset that groovy appears to be built on.
  - rcoveson 6y ago
    That would justify requiring semicolons/parentheses. It doesn't justify making them optional. The real explanation is that they were mimicking another language, Ruby, that had made that mistake.
mrec 6y ago
I think I conflate the two, and I'm not sure that's wrong. I've never seen anyone use Groovy outside Gradle. I mean why would you, if you had a choice?
- tamasnet 6y ago
  Groovy is fantastic for quickly creating domain specific languages. I've done a bunch of them over the years for different problem domains and have yet to find another solution that yields effective custom languages that are as readable and easy to implement.
- michaelcampbell 6y ago
  I have an old java (7, 8) app I maintain that whenever possible I move classes to Groovy as I am making other changes in them. I would probably do Kotlin, now, but that wasn't an option when I started this. The amount of boilerplate removed is one big win, but moreover the more functionally oriented aspects of most anything you'd do with a for-loop in java is wonderful. And with annotations such as @CompileStatic and @TypeChecked, I am able to forgo SOME of the syntactic niceties for the compile-time binding java-comparable speed.
- Tainnor 6y ago
  Back in the days when Kotlin didn't exist and even Scala was in its infancy, some people genuinely liked the JVM ecosystem and even aspects of Java itself, but were turned off by the verbosity of Java. Those were the people that started using Groovy and also projects such as Grails (especially since they saw the success of Rails and Django and wanted to emulate that). Also, I guess some people genuinely like gradual typing, although I've never found much use for it. Nowadays, I wouldn't pick up Groovy anymore, but there was a time where it was basically that, or Java (or a different ecosystem entirely; or something like JRuby / Jython).
- imtringued 6y ago
  There are worse things than using Grails. For example using straight up Spring. Grails is a sane wrapper around Spring so you can easily bring regular Java developers into a sane ecosystem. For example Grails' Gorm is the only sane way of using Hibernate in the entire JVM ecosystem. Using Hibernate directly will drain your sanity very quickly.
EE84M3i 6y ago
>you can override a val x:Int with a val x:Int get() Could you expand on this? I don't follow what you mean. Are you talking about some form of shadowing?
- EddieRingle 6y ago
  They're confusing a read-only property that can be overridden with one that's made final.
- usrusr 6y ago
  Kotlin is playing it fast and loose with blurring the line between fields and bean-style properties. In Java you could have a public final field and it was obvious that it was immutable (unless referencing a mutable object). Kotlin, in an attempt to match Groovy in syntax cuteness, allows to declare a val (supposedly the equivalent of a java final field) that is actually not backed by memory at all but a getter method in disguise. val x: Int // this is an immutable value val y: Int // this is an immutable Function0<Int> that is executed each time and but pretends to be a val get() = System.currentTimeMillis()
  - ptx 6y ago
    C# also does this, and so do Python, JavaScript and Visual Basic. Java is the odd one out by not supporting properties.
    - Too 6y ago
      Supporting properties is one thing, having assignments copy the backing property as a lazy evaluated function-pointer another, even if value is supposedly a int. Python getter properties are evaluated instantly on assignment. To convert them back into function-pointers like the Kotlin example above you really have to go out of your way by deep diving into inspect module. The result is a property-object which is not assignable to a int-variable, but type checking probably wouldn't go this deep as inspect naturally is very dynamic in its nature. My guess is Kotlin does this as a way of structural typing, if it walks like a int and talks like an int it is an int.
cmehdy 6y ago
Writing Groovy scripts in JMeter (for some custom requests) when doing distributed performance testing was a good way to enjoy pretty much anything else afterwards. I suppose I should more accurately call that thing JSR223 + Groovy, all stored in an extensive XML file and edited through the JMeter UI..
- UweSchmidt 6y ago
  Off topic, but if you plan on coding your load tests I think Gatling is a better choice, you get to program in Scala which so far looks clean and readable to me.

by usrusr 6y ago

rcoveson 6y ago

Can anybody explain to me why it ever seemed like a good idea to make both: (1) Semicolons at the ends of lines and (2) Function-call parentheses, not required, and not illegal, but optional? It strikes me as an abdication of the responsibility of a designer, like making both String::substring and String::substr available as aliases one to the other. Who cares? Choose one and stick with it! Otherwise it becomes a race between linter-writers and community programmers to see if the entire ecosystem will become polluted with an ugly mix of both styles. A race which the linter-writers always lose.

zmmmmm 6y ago
Groovy was created during the time when Ruby was taking off and was dramatically improving productivity of creating basic CRUD type web sites. So Ruby had a beautiful simple syntax, and I think Groovy was an experiment to see how close you could get to that while maintaining compatibility with Java syntax. It's actually a remarkable success as far as it goes - most Java code can be copy and pasted in and is valid Groovy. But of course it only works because it optionally accepts parentheses, explicit vs implicit arguments etc. It does lead though to one of the biggest lies which is "if you know Java then you already know Groovy!" - that's just a mean trick to play on people.
- oblio 6y ago
  And to make things more interesting at some point the nearly-frozen-in-time Java started evolving again so Groovy is stuck in some sort of parallel universe because Ruby failed to get mass traction and most people are not familiar with it while Java 8+ has its own concepts that don't translate as neatly as Java 6-7 concepts translated to Groovy at the time.
- rcoveson 6y ago
  Maybe the rest of Ruby is more "beautiful" and "simple", but those adjectives don't apply to the inconsistency caused by optional code punctuation. I think Ruby users even realized this, and have since imposed strict requirements on their projects that only one style be followed. Groovy is all the more guilty for carrying the bad tradition forward. It's akin to somebody looking at the success of C and deciding that its macro system must be perfectly preserved going forward.
  - dragonwriter 6y ago
    > I think Ruby users even realized this, and have since imposed strict requirements on their projects that only one style be followed. A common set of conventions in the Ruby community uses both options for optional punctiation, with context controlling which is used for a particular case. E.g., 1. Use a single expression per line, and don't combine the line starting or ending a block with the contents, and don't use semicolons where they are unnecessary (so, semicolons are used only to separate the opening and “end” of single-line blocks.) 2. Use parens among function calls, except omit them in calls that are part of internal DSLs.
usrusr 6y ago
For Groovy the simple answer is they claimed that every piece of Java code would also work in Groovy. This wasn't ever true (well, maybe before someone decided that the equals() method is confusing), but it didn't matter, because of the "80% is plenty" mindset that groovy appears to be built on.
- rcoveson 6y ago
  That would justify requiring semicolons/parentheses. It doesn't justify making them optional. The real explanation is that they were mimicking another language, Ruby, that had made that mistake.

mrec 6y ago

I think I conflate the two, and I'm not sure that's wrong. I've never seen anyone use Groovy outside Gradle. I mean why would you, if you had a choice?

tamasnet 6y ago
Groovy is fantastic for quickly creating domain specific languages. I've done a bunch of them over the years for different problem domains and have yet to find another solution that yields effective custom languages that are as readable and easy to implement.
michaelcampbell 6y ago
I have an old java (7, 8) app I maintain that whenever possible I move classes to Groovy as I am making other changes in them. I would probably do Kotlin, now, but that wasn't an option when I started this. The amount of boilerplate removed is one big win, but moreover the more functionally oriented aspects of most anything you'd do with a for-loop in java is wonderful. And with annotations such as @CompileStatic and @TypeChecked, I am able to forgo SOME of the syntactic niceties for the compile-time binding java-comparable speed.
Tainnor 6y ago
Back in the days when Kotlin didn't exist and even Scala was in its infancy, some people genuinely liked the JVM ecosystem and even aspects of Java itself, but were turned off by the verbosity of Java. Those were the people that started using Groovy and also projects such as Grails (especially since they saw the success of Rails and Django and wanted to emulate that). Also, I guess some people genuinely like gradual typing, although I've never found much use for it. Nowadays, I wouldn't pick up Groovy anymore, but there was a time where it was basically that, or Java (or a different ecosystem entirely; or something like JRuby / Jython).
imtringued 6y ago
There are worse things than using Grails. For example using straight up Spring. Grails is a sane wrapper around Spring so you can easily bring regular Java developers into a sane ecosystem. For example Grails' Gorm is the only sane way of using Hibernate in the entire JVM ecosystem. Using Hibernate directly will drain your sanity very quickly.

EE84M3i 6y ago

>you can override a val x:Int with a val x:Int get() Could you expand on this? I don't follow what you mean. Are you talking about some form of shadowing?

EddieRingle 6y ago
They're confusing a read-only property that can be overridden with one that's made final.
usrusr 6y ago
Kotlin is playing it fast and loose with blurring the line between fields and bean-style properties. In Java you could have a public final field and it was obvious that it was immutable (unless referencing a mutable object). Kotlin, in an attempt to match Groovy in syntax cuteness, allows to declare a val (supposedly the equivalent of a java final field) that is actually not backed by memory at all but a getter method in disguise. val x: Int // this is an immutable value val y: Int // this is an immutable Function0<Int> that is executed each time and but pretends to be a val get() = System.currentTimeMillis()
- ptx 6y ago
  C# also does this, and so do Python, JavaScript and Visual Basic. Java is the odd one out by not supporting properties.
  - Too 6y ago
    Supporting properties is one thing, having assignments copy the backing property as a lazy evaluated function-pointer another, even if value is supposedly a int. Python getter properties are evaluated instantly on assignment. To convert them back into function-pointers like the Kotlin example above you really have to go out of your way by deep diving into inspect module. The result is a property-object which is not assignable to a int-variable, but type checking probably wouldn't go this deep as inspect naturally is very dynamic in its nature. My guess is Kotlin does this as a way of structural typing, if it walks like a int and talks like an int it is an int.

cmehdy 6y ago

Writing Groovy scripts in JMeter (for some custom requests) when doing distributed performance testing was a good way to enjoy pretty much anything else afterwards. I suppose I should more accurately call that thing JSR223 + Groovy, all stored in an extensive XML file and edited through the JMeter UI..

UweSchmidt 6y ago
Off topic, but if you plan on coding your load tests I think Gatling is a better choice, you get to program in Scala which so far looks clean and readable to me.