> Once again the point is that if you want to learn how to program in a specific language, you need to understand it's concepts and patterns.
And it's perfectly fine to initally learn that `.each { |name| … }` as a concept for looping over something.
> That's OK if you need a quick solution for a small problem, but it's not when your goal in itself is to learn how to program (in Ruby)...
I'm not sure what kind of new beginners you have taught (or how you learned yourself), but I always find that new beginners rarely know the whole picture anyway. There's nothing wrong with learning techniques without knowing how they work. In fact, we do it all the time: I wouldn't explain metaclasses when teaching about class methods in Ruby (although they are just an example of methods on the metaclass). I learned basic rules of derivates and how you could use them before I learnt why the rules are true; which am I very thankful for as I wouldn't even get why you would muck around with "limit approaches zero".
> If you want to learn a programming language, you inherently need to understand it.
No, if you want to know a programming language, you inherently need to understand it. If you want to learn it you can either do it from top-down (learn about specific code, then learn how they understand), bottom-up (learn about basic concepts, then combine them to real programs) or anything in between.
I'm mentioning this as someone who learnt programming top-down and spent years without really understanding anything. But I had fun! I created stuff! It would be a sad world if you had to understand everything before you were "allowed" to use it.
> The discussion is basically that a form of writing a specific block of code is easier to explain than another, although the latter is more widely used and considered the correct. Readability, though important, has little to do with choosing the correct construct to teach as to provide a good balance of the time and effort you need to put into learning.
Remember that the user has to learn blocks anyway. It's not like blocks is an advanced feature that is only used in looping; it's everywhere in Ruby! The real comparison here is "teach for, teach blocks later" or "teach #each, teach rest of blocks later".
Actually I agree that new programmers are better of starting with .each, and also that experienced ones can also benefit from an overload of .each to change the patterns they are used to. I commented on why I disagree with Zed's decision that each should be taught later before even getting to this "trollish" thread.
Regarding your second and third bullet points: As I've tried to explain before, there is a tremendous difference between someone reading "The Ruby Programming Language" and "The Ruby Way" trying to "learn" the Ruby programming language, and a person who goes from tutorial, to example, to tutorial, to built product. I can certainly relate to the latter since I started learning C and even a little Asm (thank you SoftIce) by myself when I was 12 thanks to a small stint in a cracking group. These days, though, after programming for around 17 years, when I want to use a new programming language I read on it's syntax, it's methodology, it's patterns... Let's do the analogy thing here: If you want to "learn" multiplication as a child, you have two options. Memorize the multiplication tables, since it's improbable that you'll need anything higher, or actually learn the mechanics of multiplication and how to carry numbers up to the next order of magnitude. There are two completely different monsters. In one you learn what you need to do to create something specific. In the other you learn everything there is to learn about a topic to further your understanding of a topic. Learning the how and the why are two completely different things that get emphasized depending on you needs. My point here is that we're trying to discuss the best methodology for the teaching of a language. In a book. Generally meant to leave students with a complete understanding of the subject at matter.
A small aside, I didn't mean ruby blocks on that last section, I just meant block in the general sense. In any case, I totally agree on the last line you typed. And that's what I've been trying to get the OP to understand. I agree to teach each first because of a plethora of reasons I've already discussed here, but I don't agree Zed is a "troll" because he thinks the explanation of core concepts in his book should be more linear.
"OP" here. The troll characterization it earned by throwing things like "Mixins vs. Multiple Inheritance" in the list of prerequisites necessary to understand the .each example, plus the strong "indoctrination" rant that precedes.
One could troll the for do construct example to require understanding of operational semantics, denotational semantics and / or abstract interpretation and gaulois connections, plus deriving the arithmetic rules in the calculus of constructions starting from the simple (sic) datatype definition Nat = Zero | Succ (Zero). All while ranting about the indoctrination in the evil ways of Turing machines.
And it's perfectly fine to initally learn that `.each { |name| … }` as a concept for looping over something.
> That's OK if you need a quick solution for a small problem, but it's not when your goal in itself is to learn how to program (in Ruby)...
I'm not sure what kind of new beginners you have taught (or how you learned yourself), but I always find that new beginners rarely know the whole picture anyway. There's nothing wrong with learning techniques without knowing how they work. In fact, we do it all the time: I wouldn't explain metaclasses when teaching about class methods in Ruby (although they are just an example of methods on the metaclass). I learned basic rules of derivates and how you could use them before I learnt why the rules are true; which am I very thankful for as I wouldn't even get why you would muck around with "limit approaches zero".
> If you want to learn a programming language, you inherently need to understand it.
No, if you want to know a programming language, you inherently need to understand it. If you want to learn it you can either do it from top-down (learn about specific code, then learn how they understand), bottom-up (learn about basic concepts, then combine them to real programs) or anything in between.
I'm mentioning this as someone who learnt programming top-down and spent years without really understanding anything. But I had fun! I created stuff! It would be a sad world if you had to understand everything before you were "allowed" to use it.
> The discussion is basically that a form of writing a specific block of code is easier to explain than another, although the latter is more widely used and considered the correct. Readability, though important, has little to do with choosing the correct construct to teach as to provide a good balance of the time and effort you need to put into learning.
Remember that the user has to learn blocks anyway. It's not like blocks is an advanced feature that is only used in looping; it's everywhere in Ruby! The real comparison here is "teach for, teach blocks later" or "teach #each, teach rest of blocks later".