Hacker News Reader

Comment by ashelmire | Hacker News Reader

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).

View on HN

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).

> 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.

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.

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.

> 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.

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

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.

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.

I disagree.

Consider a language which has float types, but which also allows you to declare vectors floats. However in v1 of the language, you can only initialize them and operate on their elements. So if you want to add two vectors, you'll have to write a function vector_add() which does the element-wise addition.

Then v2 comes along and adds addition, subtraction and scalar multiplication of vectors as a new feature, using the normal operators. Suddenly your code can now read like the math it represents.

You've added a language feature, but it makes it easier to read since there is less useless clutter and the code matches the original math more closely. And it's actually less to learn since you don't need to know if the vector library you had used vector_add or vectorAdd etc, you re-use the same operators as for scalar types, just as regular math does.

The point I was trying to make with the Brainfuck comparison is that Brainfuck is about as simple as they come, and as such actually very easy to read as such (replace the actual symbols with whatever you like).

It's just very difficult to comprehend what the code actually does. Writing complex programs in Brainfuck means you need to piece together constructs, and due to the simplicity of Brainfuck, these constructs can be large. As such it's actually very difficult for non-expert Brainfuck coders to recognize say a for-loop.

In higher order languages that have explicit for-loops in them, you still need to know what they are and what they do, but I argue they're easier to remember, read and reason about. As such the extra feature (a for-loop language construct) can make the language easier to read.

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.

Reply on news.ycombinator.com