I disagree about the 'each' being a 'social more' as opposed to 'for'.
The most important thing you will ever learn about conditional loops is that effectively they are all shorthand for combinations of compare statements and conditional jumps in assembly. Past that really, none are more conceptually simple than any other...
So the analogy of 'each' being "piece of cake" to 'for' being "easy" doesn't really hold to me. Nor does the extreme list of 'concepts I'd have to teach to show someone how .each... works'. They both effectively are the same level of abstraction from 'CMP' and 'J__'.
As someone who learned ruby as my first real language, 'each' made a lot of sense to me. It uses fewer words and relates more closely to the english language than 'for...' to my mind. I don't want to say this is the case for everybody, and 'for...' definitely at least has one advantage (cross language use - though I'm not sure this should be of major importance in a ruby tutorial).
But to me this page doesn't really present a convincing argument against the teaching of 'each' before 'for...'
Well, at least in Ruby, there's one way in which each is more abstracted than for; each creates a new scope, while for does not. This actually is a reason I'd prefer to teach each.
On the other hand, I agree with Zed that for is a better abstraction than each, and I disagree that each and for are at the same level of abstraction. If you're approaching it in the abstract, sure, they're both pretty high-level. But each is as close to pure functional as you get and for is plain iterative.
And assembly is iterative, so I'd call for better for giving people a sense of how the metal works. Which, I think, is important for newbies.
Yes. Its a bit of a side issue and the OP hardly mentioned it, so I thought I'd ignore it. I can see how in this way you then might see 'each' as more 'abstract', but this difference doesn't back up the OP's main points (eg. the "piece of cake"/"easy" analogy).
> On the other hand, I agree with Zed that for is a better abstraction than each, and I disagree that each and for are at the same level of abstraction. If you're approaching it in the abstract, sure, they're both pretty high-level. But each is as close to pure functional as you get and for is plain iterative.
Firstly, how one abstraction can implicitly be a 'better abstraction' than another I am not sure. Only perhaps because you (individually) understand it better or have used it before it is more useful to you.
Secondly, how is 'each' any less 'plain iterative' than 'for...' when they both do exactly the same thing (iterate)? Also, how is it more 'functional'? To me its more object-oriented in that the object is stated first, but this isn't to say it is less plain or more abstract.
> And assembly is iterative, so I'd call for better for giving people a sense of how the metal works. Which, I think, is important for newbies.
I agree that Assembly is good to learn, but not sure what you mean by calling it 'iterative'.
>Firstly, how one abstraction can implicitly be a 'better abstraction' than another I am not sure. Only perhaps because you (individually) understand it better or have used it before it is more useful to you.
That was clumsy of me. I meant to say that it was a better abstraction for teaching iterative programming, which is a good tool for getting people productive with a minimum of training.
> Secondly, how is 'each' any less 'plain iterative' than 'for...' when they both do exactly the same thing (iterate)? Also, how is it more 'functional'? To me its more object-oriented in that the object is stated first, but this isn't to say it is less plain or more abstract.
When we're talking rich objects instead of simple iterators, we are speaking more abstractly. Now, naturally, you're always using a rich object in a language like Ruby, but it's a lot easier to gloss over that with for.
>I agree that Assembly is good to learn, but not sure what you mean by calling it 'iterative'.
It's full of side effects, you're not working with clean encapsulated objects.
> Secondly, how is 'each' any less 'plain iterative' than 'for...' when they both do exactly the same thing (iterate)? Also, how is it more 'functional'? To me its more object-oriented in that the object is stated first, but this isn't to say it is less plain or more abstract.
More object oriented == more abstract. But that's basically a semantic game and kind of beside the point, which is that there are more principles of computer science lurking in each than in for. That's great if you're teaching computer science, not so much if you're teaching computer programming.
Yeah. But isn't the whole point of high level constructs that you can use and conceptualize them more easily than, and without prior understanding of, what happens at a lower-level? Just like you don't have to learn exactly how CPU registers work to learn C, you also don't have to learn all the principles of computer science behind 'each' before you can use it....
also - maybe you mean 'imperative' rather than 'iterative'?
In terms of 'abstract', I can see where you are coming from that there are more underlying principles and its more abstract from this point of view. From the point of view I was at, they are both referencing the same variables doing the same thing so its the same abstraction from a programmatic(?) point of view. Probably a poor/confusing choice of words on my part...
The most important thing you will ever learn about conditional loops is that effectively they are all shorthand for combinations of compare statements and conditional jumps in assembly. Past that really, none are more conceptually simple than any other...
So the analogy of 'each' being "piece of cake" to 'for' being "easy" doesn't really hold to me. Nor does the extreme list of 'concepts I'd have to teach to show someone how .each... works'. They both effectively are the same level of abstraction from 'CMP' and 'J__'.
As someone who learned ruby as my first real language, 'each' made a lot of sense to me. It uses fewer words and relates more closely to the english language than 'for...' to my mind. I don't want to say this is the case for everybody, and 'for...' definitely at least has one advantage (cross language use - though I'm not sure this should be of major importance in a ruby tutorial).
But to me this page doesn't really present a convincing argument against the teaching of 'each' before 'for...'