141–150 of 179 posts
Earlier quoted context omitted.
I don't see how learning how to use a language according to its conventions makes one not a programmer.
According to Zed in the article, `for` requires fewer concepts to be fully explained, which `.each` only achieves teaching people to be "Good little rubyists".
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 metho…
> 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.
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
Earlier quoted context omitted.
According to Zed in the article, `for` requires fewer concepts to be fully explained, which `.each` only achieves teaching people to be "Good little rubyists".
I don't see how learning either one makes someone less of a programmer. It seems like you have made a false dichotomy.
This is a troll, or the author completely lacks any pedagogical skills. The offending (sic) code: arr.each { |elem| puts elem } Explanation: There is a function "each" that applies to arrays. "Each", for each element in the array, binds "elem" to the element value, then executes the body of the code block. The code applies "each" to array "arr" and executes "puts elem" for each element. Concepts: variable, binding, f…
The target audience of his book has just learned what a variable and an array is. Since the book as advertized as learning "the hard way," it seems to explicitly attempt to give an insight to what the computer is doing when you tell it to do something.
That is, I sure as hell could translate a for loop to psuedo-assembly, and I could probably teach a newbie how to do the same for their mental model. I don't even begin to think how I would teach them what the computer is doing conceptually.
The target audience of his book is not coding yet. What, should we require a comprehension and vocabulary test before they test something out in a REPL?
As such, I would say Zed's pedagogy is sound.
Earlier quoted context omitted.
for-loops and .each had weird scoping rules until Ruby 1.9. In Ruby 1.9 for some weird reason they fixed .each but not for-loops. No idea why. So, if you're saying use .each for technical solution to a problem in Ruby, then your proposed solution only works in some versions of Ruby.
How did .each have weird scoping pre-1.9? I've run across problems with for-loops, but .each has always behaved predictably, even in 1.8. Could you perhaps provide an example of code using .each that does the wrong thing in 1.8, but the right thing in 1.9?
a = 0
[1, 2, 3].each { |a| }
a # => 3Earlier quoted context omitted.
To clarify, I don't think my original post implied that you were against teaching people how to learn each. Nor do I want to start out teaching beginning rubyists everything all at once. It was more to point out how important the mindset of each is. That's the mindset that you want to reach. And I'm not sure that teaching a construct that you'll never end up using is helpful. I think it just creates a mental construc…
I'm an experienced Rubyist. Really. I started using it in 2002. Depending on the context, I will use a for-loop in my Ruby. Not often, preferring the power that #each provides and backs (e.g., all of Enumerable), but there are times when a for loop is absolutely the clearest way to write what I'm doing. The only place that I'd change what Zed said with respect to this particular example is that, in Ruby, there are so…
Zed is making a number of points, so I don't want to sound like I'm arguing against all of them. But particularly on the matter of each... if all we were talking about were each I think Zed would have an excellent point. But wrapped up with each are all of the other fantastic enumerable methods like map/collect, select/find, inject/reduce, as well as each_cons, each.with_index, map.with_index, etc. These are where th…
You are right, and once again I am not against using functional programming, OOP, message passing, or any of the things I mention about .each. I'm against using .each as a first looping construct. In fact, go look at your supposedly better last line of code and tell me if you think a newbie would even begin to comprehend that? Hell I'm a programming veteran and Ruby veteran and I want to metaphorically punch you in t…
Earlier quoted context omitted.
each is definitively transferable for many languages. Javascript has Array.map(), which is almost the same: var numbers = [1, 4, 9]; var roots = numbers.map(Math.sqrt); /* roots is now [1, 2, 3], numbers is still [1, 4, 9] */ C# has IEnumerable.Select(): IEnumerable squares = Enumerable.Range(1, 10).Select(x => x * x); /* squares is [1, 4, 9, 16, ...] */ Python has map(), which isn't OOP but accomplishes mostly the s…
The examples you give are equivalents to Enumerable#map, not Enumerable#each. In JavaScript, the closest equivalent to #each is Array.forEach(). In C# and Python, while methods equivalent to #each may exist (I'd have to double-check the docs to be sure), the recommended way to accomplish the same functionality as #each is...a for loop.
Earlier quoted context omitted.
The examples you give are equivalents to Enumerable#map, not Enumerable#each. In JavaScript, the closest equivalent to #each is Array.forEach(). In C# and Python, while methods equivalent to #each may exist (I'd have to double-check the docs to be sure), the recommended way to accomplish the same functionality as #each is...a for loop.
C# doesn't have an Enumerable.ForEach (but it does have a List.ForEach). More significantly, it has a Parallel.ForEach which is recommended for iterations that can be done in parallel.
It's trivial to add it as an extension method though. I've seen it done, and I wanted to punch them for using needlessly overcomplex idioms. It's discussed here http://stackoverflow.com/questions/225937/foreach-vs-somelis...
> More significantly, it has a Parallel.ForEach which is recommended for iterations that can be done in parallel.
Yes and no. I've seen Parallel.ForEach misused more often than I've seen it used right. If you have a small ( < 16) number of loop iterations then don't bother with Parallel.ForEach. If each of those items to process is time-consuming then use tasks and Task.WaitAll for them to complete. Where Parallel.ForEach works well is where there are a very large number of iterations, and the scheduler can split batches of them up between cpu cores, and even tune the batch size as the run progresses. That's just not going to happen when there are 5 loop iterations.