4 ms·

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,

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.

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.