5 ms·

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 rubyi

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 construct that you'll have to overcome at a later stage. I don't think .each is so much harder to learn that it justifies getting a beginner in the wrong mindset. Though to be fair I've only ever explained it to people who've already known some programming, so there is a possibility that I'm underestimating the difficulty of teaching it. In any event, I thought the essay was totally worth the read even if I didn't agree with all of it. Thank you for it.

edwinnathaniel 14y ago
2 keywords: - First loop programming construct - Beginner Exhale. Inhale. Now back to the blog post and see how many constructs to understand .each correctly vs "just accept it for now that this is how it should work, we'll come back later". Have you ever read such books? the ones with "we'll come back to it later".
wging 14y ago
>I'm not sure that teaching a construct that you'll never end up using is helpful. But that was precisely Zed's point! You will certainly end up using it, though you may never use it in Ruby. .each is not transferable, and for-loops are. Zed's teaching Ruby as an introduction to programming, not just to Ruby in itself.
- icebraining 14y ago
  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<int> 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 same: names = ["mary", "john"] caps = map(lambda name: name.upper(), names)
  - LeafStorm 14y ago
    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.
    - noblethrasher 14y ago
      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.
      - SideburnsOfDoom 14y ago
        > C# doesn't have an Enumerable.ForEach 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-somelist-foreach/226299#226299 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.
    - Argorak 14y ago
      #each can be seen as special case of #map where the mapped function returns its argument.
  - djacobs 14y ago
    #each and #map are not meant to be the same thing. #each in any language is meant only for side-effects. If you only care about the return value, #map is a much better choice. (Similarly, if you only care about the return value but want many items condensed into one "reduced" item, you want #reduce.)
- tsurantino 14y ago
  .each as a concept of "iteration" is transferrable, no? Also, I think there are some serious consequences when programming is taught in such a "diluted" way. As a programmer who is constantly learning new concepts/languages, I am continually understanding the very real trade-offs when I write something in Ruby vs. C, not just in functionality, but in the design of the language itself. By diluting, all languages start to blend in this ball where they become indistinguishable. Besides, if Zed is teaching an introduction to programming, it becomes completely arbitrary what language he chooses, and it therefore means he doesn't need to do variations of his lessons in other languages - unless of course he was going to meaningfully divulge into how these languages propose new ways of approaching a problem, etc. (but this would render this article's arguments moot, to a degree)
halostatue 14y ago
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 some side-effects to using a for-loop instead of #each. Most of the time, they don't matter, but they do exist. (So in using the for-loop to teach programming, I'd have a footnote that says that the preferred way in Ruby will be discussed later.)
- judofyr 14y ago
  Interesting. Any examples of where you find for more clear than #each? I feel #each is inheritly more clear because it's explicit. Every time I see a for-loop in Ruby I have to remind myself that "oh, that's actually just calling #each". It's also easier going from e.g. #each to #each_with_index, or #each_cons/#each_slice.
  - halostatue 14y ago
    Mostly? DSLs and templates. The goal of an in-language DSL isn't necessarily to feel like you're writing that language (I wrote a DSL once that made it easy to generated shared enums for C++, C#, Java, and Ruby. It was Ruby behind the scenes, but because it was declarative, it didn't feel like Ruby. Additionally, the templates used to generate the resulting code almost exclusively used for loops.) I almost exclusively use the #each-ish in my libraries and in the backing code for such DSLs or templates.

edwinnathaniel 14y ago

2 keywords: - First loop programming construct - Beginner Exhale. Inhale. Now back to the blog post and see how many constructs to understand .each correctly vs "just accept it for now that this is how it should work, we'll come back later". Have you ever read such books? the ones with "we'll come back to it later".

wging 14y ago

>I'm not sure that teaching a construct that you'll never end up using is helpful. But that was precisely Zed's point! You will certainly end up using it, though you may never use it in Ruby. .each is not transferable, and for-loops are. Zed's teaching Ruby as an introduction to programming, not just to Ruby in itself.

icebraining 14y ago
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<int> 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 same: names = ["mary", "john"] caps = map(lambda name: name.upper(), names)
- LeafStorm 14y ago
  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.
  - noblethrasher 14y ago
    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.
    - SideburnsOfDoom 14y ago
      > C# doesn't have an Enumerable.ForEach 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-somelist-foreach/226299#226299 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.
  - Argorak 14y ago
    #each can be seen as special case of #map where the mapped function returns its argument.
- djacobs 14y ago
  #each and #map are not meant to be the same thing. #each in any language is meant only for side-effects. If you only care about the return value, #map is a much better choice. (Similarly, if you only care about the return value but want many items condensed into one "reduced" item, you want #reduce.)
tsurantino 14y ago
.each as a concept of "iteration" is transferrable, no? Also, I think there are some serious consequences when programming is taught in such a "diluted" way. As a programmer who is constantly learning new concepts/languages, I am continually understanding the very real trade-offs when I write something in Ruby vs. C, not just in functionality, but in the design of the language itself. By diluting, all languages start to blend in this ball where they become indistinguishable. Besides, if Zed is teaching an introduction to programming, it becomes completely arbitrary what language he chooses, and it therefore means he doesn't need to do variations of his lessons in other languages - unless of course he was going to meaningfully divulge into how these languages propose new ways of approaching a problem, etc. (but this would render this article's arguments moot, to a degree)

halostatue 14y ago

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 some side-effects to using a for-loop instead of #each. Most of the time, they don't matter, but they do exist. (So in using the for-loop to teach programming, I'd have a footnote that says that the preferred way in Ruby will be discussed later.)

judofyr 14y ago
Interesting. Any examples of where you find for more clear than #each? I feel #each is inheritly more clear because it's explicit. Every time I see a for-loop in Ruby I have to remind myself that "oh, that's actually just calling #each". It's also easier going from e.g. #each to #each_with_index, or #each_cons/#each_slice.
- halostatue 14y ago
  Mostly? DSLs and templates. The goal of an in-language DSL isn't necessarily to feel like you're writing that language (I wrote a DSL once that made it easy to generated shared enums for C++, C#, Java, and Ruby. It was Ruby behind the scenes, but because it was declarative, it didn't feel like Ruby. Additionally, the templates used to generate the resulting code almost exclusively used for loops.) I almost exclusively use the #each-ish in my libraries and in the backing code for such DSLs or templates.