4 ms·

As a rubyist of 10 years, a few thoughts. I wasn't aware of these upcoming features, but to some extent they make a lot of sense. Except... yeah, those symbol c

As a rubyist of 10 years, a few thoughts. I wasn't aware of these upcoming features, but to some extent they make a lot of sense. Except... yeah, those symbol choices. I agree that @1, @2 etc look totally wrong, and maybe that subjective view will change - but scope-wise, having @-variables that are nothing to do with the current instance would utterly ruin scannability. On the other side, I suspect Rubocop will very quickly react to outlaw it, so no big problem as far as my code goes. I very rarely use &method(:foo). I find it ugly, and &:foo is more useful in 98% of circumstances. Maybe I would use it if it were shorter - but .:foo seems wrong. I feel like it would, again, be harder to scan. That said, the more I let it sit in my brain, the less passionately I object. > Still, I was disappointed when the safe navigation operator as introduced, as it basically acknowledged that it’s fine to return nil I think this is indicative of the crux of the problem. Optimizing for programmer happiness implies you know what programmers need. Some programmers have no problem working with nils - we've long since accepted them, even embraced them. The safe navigator pattern almost gave us a way of implementing a null object pattern with literally no work, while screaming out to the world "this method accepts nil, so watch out". I would much prefer code that accepts nil as a fact of life than code that denies its very existence. I feel that "hacky code" will be well served by these changes, and I think that "production code" will be better served by tight Rubocop rules. So, everyone's happy!

lloeki 8y ago
> I very rarely use &method(:foo). I find it ugly, and &:foo is more useful in 98% of circumstances. Maybe I would use it if it were shorter - but .:foo seems wrong. I feel like it would, again, be harder to scan. Ever since the near-death of the hash rocket syntax have these days been coming as you can already see the same line of thinking coming out of it. Superficially the introduction of the symbolic hash syntax that aligns it with yaml/js and saves a few chars was locally good for readability, yet fundamentally it could not deprecate the hash rocket because if one of your keys is not a literal symbol then you're toast and have to use hash rockets in your code, which means you end up with mixed patterns throughout your code and thus have to 1/ keep two tokenisation branches inside your head and 2/ make decisions about the syntax to use every single time you write a hash, which looks like small things but long term sand in a gearbox grinds it to a stop. At some point you end up with all those little syntactic sugary things which make sense locally but which overall makes for increasingly heavy cognitive overload and you end up in a tar pit through normalization of deviance. When Ruby began to take off, people said it was like Perl's heir, only readable. Today as both a Rubyist and a former Perlist, I do long for Perl (and violently enforce readability rules on Ruby projects I own)

lloeki 8y ago

> I very rarely use &method(:foo). I find it ugly, and &:foo is more useful in 98% of circumstances. Maybe I would use it if it were shorter - but .:foo seems wrong. I feel like it would, again, be harder to scan. Ever since the near-death of the hash rocket syntax have these days been coming as you can already see the same line of thinking coming out of it. Superficially the introduction of the symbolic hash syntax that aligns it with yaml/js and saves a few chars was locally good for readability, yet fundamentally it could not deprecate the hash rocket because if one of your keys is not a literal symbol then you're toast and have to use hash rockets in your code, which means you end up with mixed patterns throughout your code and thus have to 1/ keep two tokenisation branches inside your head and 2/ make decisions about the syntax to use every single time you write a hash, which looks like small things but long term sand in a gearbox grinds it to a stop. At some point you end up with all those little syntactic sugary things which make sense locally but which overall makes for increasingly heavy cognitive overload and you end up in a tar pit through normalization of deviance. When Ruby began to take off, people said it was like Perl's heir, only readable. Today as both a Rubyist and a former Perlist, I do long for Perl (and violently enforce readability rules on Ruby projects I own)