3 ms·
You give a list of things you'd have to teach before you can explain how the #each works, but are you sure you really need to teach how #each works to explain w
by tinco 14y ago
You give a list of things you'd have to teach before you can explain how the #each works, but are you sure you really need to teach how #each works to explain what it does?
I think I would rather teach that #each is a method that iterates over the elements of the array calling the code block for every element.
This only requires you to teach variables, arrays, the if statement, goto/jumps and objects with their methods.
And frankly it being ruby, I don't think it's bad at all to teach objects and their methods, before teaching iterations.
Maybe it's not in line with your hard way philosophy, but explaining for loops with goto/jumps seems a bit abstract to me. Don't you need to explain how instructions are mapped to memory addresses and the instruction register to really do so?
An each method can be explained with a simple recursive function, no need to dive into hocus pocus CPU details.
- dllthomas 14y ago> explaining for loops with goto/jumps seems a bit abstract to me I assume you mean "concrete" - goto/jumps is how it's done in the machine code; to get less abstract we'd have to start looking at how the processor is built.
- tinco 14y agoFrom the vantage point of the Ruby programmer, the only concrete things are the Ruby statements used to model your desired behaviour. When you're teaching goto/jumps you'd have to either teach another programming language (raw instructions) which would make it more concrete, but would also raise a lot more questions about how Ruby works, or teach goto in terms of Ruby code, which would make it fairly abstract :P