3 ms·

I am forced to read them and fix bugs related to the ambiguous syntax parsing. “Nobody forces you to use it” can justify just about any insane addition to a pr

I am forced to read them and fix bugs related to the ambiguous syntax parsing. “Nobody forces you to use it” can justify just about any insane addition to a programming language. Nobody forces you to use any of C++’s zillion and one features, but because they exist you have to contend with their consequences even if you try to limit yourself to modern conventions. We didn’t need two ways to define methods, one of which parses insanely in order to save a few keystrokes. Adding this didn’t make the language better, it made it more complicated for virtually zero net gain.

vidarh 3y ago
If you're not in a team where you're in a position to influence the choices used, this will be far down the list of your problems. My sympathies. We have several more ways to define methods already, and always have. If you think this gives us two perhaps the problem is you don't know the language very well. Choices like this, to create options to adjust how the code reads has always been central to the design of Ruby. It's an odd thing to be annoyed with Ruby over. "Parses insanely" is highly subjective. It parses exactly as you should expect it to if familiar with Ruby. Some of it is not ideal, and will likely be addressed with adjustments to the grammar. In the meantime the simple fix is to add parentheses whenever in doubt.
- stouset 3y ago
  > We have several more ways to define methods already, and always have. If you think this gives us two perhaps the problem is you don't know the language very well. Resorting to semantic-lawyering doesn’t add to your argument, it detracts from it. You know the point I was making.
  - vidarh 3y ago
    I don't think the point you were making has any validity. It's not semantic-lawyering given that other ways of defining methods are common in larger Ruby code-bases, so you're already going to need to deal with a variety of far more complex things. If "end-less" defs is enough to throw you, then perhaps Ruby just isn't the language for you, and that's fine.

vidarh 3y ago

If you're not in a team where you're in a position to influence the choices used, this will be far down the list of your problems. My sympathies. We have several more ways to define methods already, and always have. If you think this gives us two perhaps the problem is you don't know the language very well. Choices like this, to create options to adjust how the code reads has always been central to the design of Ruby. It's an odd thing to be annoyed with Ruby over. "Parses insanely" is highly subjective. It parses exactly as you should expect it to if familiar with Ruby. Some of it is not ideal, and will likely be addressed with adjustments to the grammar. In the meantime the simple fix is to add parentheses whenever in doubt.

stouset 3y ago
> We have several more ways to define methods already, and always have. If you think this gives us two perhaps the problem is you don't know the language very well. Resorting to semantic-lawyering doesn’t add to your argument, it detracts from it. You know the point I was making.
- vidarh 3y ago
  I don't think the point you were making has any validity. It's not semantic-lawyering given that other ways of defining methods are common in larger Ruby code-bases, so you're already going to need to deal with a variety of far more complex things. If "end-less" defs is enough to throw you, then perhaps Ruby just isn't the language for you, and that's fine.