5 ms·

I agree and disagree. The more features the language has, the harder it is to read. And using @ for positional arguments when it’s already used for instance v

I agree and disagree. The more features the language has, the harder it is to read. And using @ for positional arguments when it’s already used for instance variables is a questionable choice. But on the other hand, the syntax for these blocks has always been clunky. But Ruby is all about options. You can do things the way you want, when you want. That’s the happiness you achieve. But it does become more difficult to read for newcomers and devs not up on the latest updates, which is a major sacrifice. Some of these new features are blessings though. The safe navigation operator saves lots of checks and I wish I had it in JavaScript and other languages (rather than checking for a property first).

intertextuality 8y ago
> Ruby is all about options Err, is that why things like Rails are convention over configuration? I personally would rather have consistency throughout ruby codebases than various random solutions people have come up with. @1 and @2 is more difficult to read, full stop. It's more difficult for newcomers because it's more random "magic" that one has to learn, and it's difficult for ruby devs when they read other people's code and have to discern what @1, @2, @3 might possibly be. At least variable names give information, if done properly. Matz even stated this was a compromise. I think it's utterly unsatisfactory for Ruby to just accept this as it is currently. There has to be a better solution than @1 and @2.
- kenforthewin 8y ago
  Ruby != Rails. I think it makes sense that the language remains flexible while the framework is opinionated. I probably won't use @1 et al in my projects, that's where enforcing consistency via rubocop comes into play.
  - intertextuality 8y ago
    Sure, ruby isn't rails. But a lot of tools are also opinionated (like Rubocop, even.. or Brakeman, etc). One can always change values but there -are- default configurations that people generally tend to go with. Having consistency in the language is also better overall for the community. If you read through a new codebase, having consistent patterns makes that process significantly better. @1 and @2 are only going to make things less readable. People will choose the easier option and never go back to refactor it once completed. It's a horrible change for Ruby.
rob74 8y ago
Having lots of options to write things optimizes the happiness of the developer writing the code, but reduces the happiness of the developer reading the code (which might be the same developer, a few months later). That's one of the things Go got right IMHO (although some people hate it, because they feel constrained if they're not able to write code in some "clever" way).
magicalhippo 8y ago
> The more features the language has, the harder it is to read. So you're saying Brainfuck is a really easy language to read? Surely there's a balance. The key is you want your language to convey the intentions of the programmer. Features can help do that, but they can also cause convolution, hiding the intentions.
- betenoire 8y ago
  Parent didn't claim the inverse as you say. That's bad logic, it assumes a weak position that wasn't made and is easy to refute. Post hoc
  - magicalhippo 8y ago
    Brainfuck is about as simple as they come. If you were to evolve Brainfuck into something like Ruby, you have to add a lot of features. The poster literally said "[t]he more features the language has, the harder it is to read". From that it follows that something like Ruby is harder to read than Brainfuck. I disagree with that absolute, and I was trying to say that I think it's more nuanced. Sometimes a feature can be such a natural addition to the language that it explains itself, so to speak, and makes the code easier to read even to those who are new to the feature.
    - magicalhippo 8y ago
      If the Brainfuck to Ruby example is too extreme for you, consider classical Pascal with Object Pascal (Delphi). Object Pascal has a lot more features today than the classical Pascal language. I think that certain code is more readable expressed in Object Pascal than in classic Pascal, due to these features.
    - ashelmire 8y ago
      No, you’re making an incorrect extrapolation. Obviously there’s a minimum number of features for readability. Example: dictionaries use a core of a few thousand words. Yes, they could use less or more, but it’s an optimization. Obviously a language that doesn’t allow sufficient expression isn’t easy to use either. But still, the more rules, the more you have to learn and that means harder to read in that respect.

intertextuality 8y ago

> Ruby is all about options Err, is that why things like Rails are convention over configuration? I personally would rather have consistency throughout ruby codebases than various random solutions people have come up with. @1 and @2 is more difficult to read, full stop. It's more difficult for newcomers because it's more random "magic" that one has to learn, and it's difficult for ruby devs when they read other people's code and have to discern what @1, @2, @3 might possibly be. At least variable names give information, if done properly. Matz even stated this was a compromise. I think it's utterly unsatisfactory for Ruby to just accept this as it is currently. There has to be a better solution than @1 and @2.

kenforthewin 8y ago
Ruby != Rails. I think it makes sense that the language remains flexible while the framework is opinionated. I probably won't use @1 et al in my projects, that's where enforcing consistency via rubocop comes into play.
- intertextuality 8y ago
  Sure, ruby isn't rails. But a lot of tools are also opinionated (like Rubocop, even.. or Brakeman, etc). One can always change values but there -are- default configurations that people generally tend to go with. Having consistency in the language is also better overall for the community. If you read through a new codebase, having consistent patterns makes that process significantly better. @1 and @2 are only going to make things less readable. People will choose the easier option and never go back to refactor it once completed. It's a horrible change for Ruby.

rob74 8y ago

Having lots of options to write things optimizes the happiness of the developer writing the code, but reduces the happiness of the developer reading the code (which might be the same developer, a few months later). That's one of the things Go got right IMHO (although some people hate it, because they feel constrained if they're not able to write code in some "clever" way).

magicalhippo 8y ago

> The more features the language has, the harder it is to read. So you're saying Brainfuck is a really easy language to read? Surely there's a balance. The key is you want your language to convey the intentions of the programmer. Features can help do that, but they can also cause convolution, hiding the intentions.

betenoire 8y ago
Parent didn't claim the inverse as you say. That's bad logic, it assumes a weak position that wasn't made and is easy to refute. Post hoc
- magicalhippo 8y ago
  Brainfuck is about as simple as they come. If you were to evolve Brainfuck into something like Ruby, you have to add a lot of features. The poster literally said "[t]he more features the language has, the harder it is to read". From that it follows that something like Ruby is harder to read than Brainfuck. I disagree with that absolute, and I was trying to say that I think it's more nuanced. Sometimes a feature can be such a natural addition to the language that it explains itself, so to speak, and makes the code easier to read even to those who are new to the feature.
  - magicalhippo 8y ago
    If the Brainfuck to Ruby example is too extreme for you, consider classical Pascal with Object Pascal (Delphi). Object Pascal has a lot more features today than the classical Pascal language. I think that certain code is more readable expressed in Object Pascal than in classic Pascal, due to these features.
  - ashelmire 8y ago
    No, you’re making an incorrect extrapolation. Obviously there’s a minimum number of features for readability. Example: dictionaries use a core of a few thousand words. Yes, they could use less or more, but it’s an optimization. Obviously a language that doesn’t allow sufficient expression isn’t easy to use either. But still, the more rules, the more you have to learn and that means harder to read in that respect.