Earlier quoted context omitted.
> The fact that you can read a piece of code doesn't mean that you understand it. Therein lies the troll. Understanding is not figuring out how to derive the code from first principles. If that were true, you shouldn't drive a car because you can't explain the carburator mix ratio on top of your head. Understanding means being able to copy a pattern and adapt it to a new situation. I never wrote a line of Ruby in my…
Understanding how to drive vs building a car is the same thing as understanding how to use a program vs building the program. 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. It's akin to the fact that if you want to learn how to build a car, you need to understand it's mechanics. You can easily take whatever you find in the in…
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".