Before I learned Ruby, I knew C, Obj-C, C++, Java...all languages that have and use "for" extensively. Coming to Ruby and learning "each" was an eye opening experience for me. Suddenly, the whole notion of iterators become clear to me. (While I had used them in the past, I had only marginally understood them.) After using "each" for a while, I came to realize that I was programming in a functional style without even knowing it.
Earlier today I read through Rich Hickey's posts explaining reducers and actually used them to get crazy performance gains from some Clojure code I was writing...but I highly doubt I would've gotten there without Ruby's "each".
I've seen Zed argue on this point before, and I've always been dubious of his "concern". The one point he makes here, though, that makes me side with him is that "for" is easier to teach than "each". Yes. A hundred times: yes!
The point I will disagree with him on is that "for" and "each" are interchangeable. Semantically, yes. Performance-wise, probably. But stylistically, "each" is a gateway drug to functional programming, and that should not be taken for granted.
(Edit: Where this all breaks down, and where I think Zed is experiencing frustration, is that while some people might have had a good reason for using "each", over time it became a social more. Now people teach and even enforce the use of "each" without being able to explain why. That doesn't mean one should avoid teaching "use each, not for", but it does mean that one should go and find out why.)
Start with "for". Teach "each".
...then go learn Clojure because hot DAMN reducers are going to revolutionize the way we program (but that's another topic for another day).
Well remember, I'm not against .each at all. I'm against it as a first looping construct for beginners. I even start people off in my book by sneaking in functional programming, again because it's easier to teach. They even write a game that is basically one giant sequence of mostly tail calls without knowing it.
Right, I think where people have to get over themselves is that teaching something is often very different from using something. When I was being trained as a chemist, I was started with techniques that were over 150 years old, and that no one in their right mind would use in a professional lab (you really think chemists do tedious titrations when you can buy a pH meter that's 10x more accurate?).
In other words: programmers don't understand pedagogy. Nothing really new there.
I've very much enjoyed the books though...went back and did "Learn C the Hard Way" even though I've been using C for almost 18 years. Can't wait to read "Learn Clojure the Hard Way"... ;-)
Earlier today I read through Rich Hickey's posts explaining reducers and actually used them to get crazy performance gains from some Clojure code I was writing...but I highly doubt I would've gotten there without Ruby's "each".
I've seen Zed argue on this point before, and I've always been dubious of his "concern". The one point he makes here, though, that makes me side with him is that "for" is easier to teach than "each". Yes. A hundred times: yes!
The point I will disagree with him on is that "for" and "each" are interchangeable. Semantically, yes. Performance-wise, probably. But stylistically, "each" is a gateway drug to functional programming, and that should not be taken for granted.
(Edit: Where this all breaks down, and where I think Zed is experiencing frustration, is that while some people might have had a good reason for using "each", over time it became a social more. Now people teach and even enforce the use of "each" without being able to explain why. That doesn't mean one should avoid teaching "use each, not for", but it does mean that one should go and find out why.)
Start with "for". Teach "each".
...then go learn Clojure because hot DAMN reducers are going to revolutionize the way we program (but that's another topic for another day).