Your comment is hyperbole in every way. The post made 2 points:
- we should be calling "idioms" "social mores"
- we should teach beginners simpler constructs instead of idiomatic ones, especially `for` instead of `.each` in ruby.
Note that you agreed with his second point.
He has no responsibility to address the upsides of `.each`, since that's not the point of his article. He wasn't talking about advanced programmers, he was specifically addressing why he didn't teach `.each` in his book, and why it shouldn't be taught to other beginner programmers.
“for” is the raw loopy stuff out of which other looping constructs are made—it’s fairly arbitrary. If you’re implementing an iteration construct, then by all means “for” is the thing to use. But in normal use it’s best to express your intent through more common, composable constructs such as maps, folds, and zips. There’s certainly less overhead in reading a non-trivial loop written as a composition than one written as a raw “for”.
So I don’t think “each” is any better than “for”—in addition to having uglier syntax in Ruby, neither conveys any more information than the other. It’s the same with std::for_each in C++, present only for consistency with its more meaningful siblings.
If you didn't get my intent, the last part of the article which you recommended was highly biased and after reading it I was left questioning the author's motive.
- we should be calling "idioms" "social mores"
- we should teach beginners simpler constructs instead of idiomatic ones, especially `for` instead of `.each` in ruby.
Note that you agreed with his second point.
He has no responsibility to address the upsides of `.each`, since that's not the point of his article. He wasn't talking about advanced programmers, he was specifically addressing why he didn't teach `.each` in his book, and why it shouldn't be taught to other beginner programmers.