4 ms·

Even for one liners I think it's a bad idea. It's not that tough to do .map{ |course| course.some_method + some_str } instead of .map { @1.some_method + some_st

Even for one liners I think it's a bad idea. It's not that tough to do .map{ |course| course.some_method + some_str } instead of .map { @1.some_method + some_str }. The latter is extremely ugly and does not belong in Ruby whatsoever. I'm not budging on this.

yebyen 8y ago
You can keep your opinion, I don't need to spend any more time trying to convince you, but to be pedantic one last time, you omitted the part of that snippet that would have made it clear the named parameter is not needed and unnecessarily verbose: courses.map{|course| course.some_method + some_str} is unabashedly and unnecessarily verbose, I know it's a course as it's from courses. No need to repeat yourself twice. courses.map{@1.some_method + some_str} by comparison is perfectly clear, once you know the syntax. Edit: I just installed ruby-2.7-head and I made a typo, first thought it is not permitted in a do-block. It is. I think it's bad to use this in a do-block. But like I said, there are already plenty of ways to make your code into unreadable garbage, it's up to the author to make a good decision. Some programmers will choose poorly no matter how hard you try to prevent it. In my opinion, this syntax is for one-liner blocks only. You should avoid using tools in incorrect ways, and code that has numbered parameters strewn everywhere without any attention to naming, is guaranteed to have more than just one bad code smell in it. But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers.
- intertextuality 8y ago
  In that example, fair enough. However often one unpacks a tuple or operates on a hash, where it's not immediately obvious what the inner values are. So we can bikeshed if you want, but I still think it's a bad idea (and looks very ugly).
- jimbokun 8y ago
  "But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers." That is pretty much entirely the point of higher level programming languages. Like preventing you from allocating and freeing memory on your own, because you might screw it up. Or removing pointer arithmetic. Or reducing the scope of mutability. Or preventing access to "private" object variables. Many programming language features are basically guards to make it less likely you cut your hand off.
  - yebyen 8y ago
    Those are all scary indeed. Ways you can cut your hand off. Has a nice ring to it, sounds like something to worry about more than "ways you can write unreadable garbage code that not even the author can still parse for themselves in their head." Nobody is arguing that there aren't ways to misuse this new feature. There obviously are! But I can tell you we have plenty of time to call the ways out and warn everyone not to do those things, before ruby-2.7 will be affecting any legacy codebases. If you feel strongly about this, the time to argue about it is definitely now, not after the first 2.7 release is already cut. It makes the list of un-googlable idiomatic syntaxes that you must learn and keep in a list, in order to guarantee you won't ever find a bit of Ruby code that you can't understand, marginally longer. There are several such features planned in the ruby-2.7-head now. Is this really the worst of them?

yebyen 8y ago

You can keep your opinion, I don't need to spend any more time trying to convince you, but to be pedantic one last time, you omitted the part of that snippet that would have made it clear the named parameter is not needed and unnecessarily verbose: courses.map{|course| course.some_method + some_str} is unabashedly and unnecessarily verbose, I know it's a course as it's from courses. No need to repeat yourself twice. courses.map{@1.some_method + some_str} by comparison is perfectly clear, once you know the syntax. Edit: I just installed ruby-2.7-head and I made a typo, first thought it is not permitted in a do-block. It is. I think it's bad to use this in a do-block. But like I said, there are already plenty of ways to make your code into unreadable garbage, it's up to the author to make a good decision. Some programmers will choose poorly no matter how hard you try to prevent it. In my opinion, this syntax is for one-liner blocks only. You should avoid using tools in incorrect ways, and code that has numbered parameters strewn everywhere without any attention to naming, is guaranteed to have more than just one bad code smell in it. But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers.

intertextuality 8y ago
In that example, fair enough. However often one unpacks a tuple or operates on a hash, where it's not immediately obvious what the inner values are. So we can bikeshed if you want, but I still think it's a bad idea (and looks very ugly).
jimbokun 8y ago
"But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers." That is pretty much entirely the point of higher level programming languages. Like preventing you from allocating and freeing memory on your own, because you might screw it up. Or removing pointer arithmetic. Or reducing the scope of mutability. Or preventing access to "private" object variables. Many programming language features are basically guards to make it less likely you cut your hand off.
- yebyen 8y ago
  Those are all scary indeed. Ways you can cut your hand off. Has a nice ring to it, sounds like something to worry about more than "ways you can write unreadable garbage code that not even the author can still parse for themselves in their head." Nobody is arguing that there aren't ways to misuse this new feature. There obviously are! But I can tell you we have plenty of time to call the ways out and warn everyone not to do those things, before ruby-2.7 will be affecting any legacy codebases. If you feel strongly about this, the time to argue about it is definitely now, not after the first 2.7 release is already cut. It makes the list of un-googlable idiomatic syntaxes that you must learn and keep in a list, in order to guarantee you won't ever find a bit of Ruby code that you can't understand, marginally longer. There are several such features planned in the ruby-2.7-head now. Is this really the worst of them?