The Ruby community does not say "you should not learn iteration using for loops." It says "if you're (still) using for loops for anything but performance reasons, you probably don't understand enough about Ruby to consider yourself an expert."
Programming Languages Have Social Mores Not Idioms
71–80 of 179 posts
Re: Programming Languages Have Social Mores Not Idioms
#72Earlier quoted context omitted.
I see your concern, if I was a beginner and I googled around I might be inclined to learn the supposedly good looping which might be difficult.
Oh, no concern at all about the ruby style guide. I even point people at it in the book so they can start grasping and writing code with other people. My mention of the guide is not intended as a knock on the guide at all.
Got it. Thanks for the clarification.
Re: Programming Languages Have Social Mores Not Idioms
#73Why would you need to teach inheritance, mixins, message passing, enumerable, etc. to teach .each as a first looping construct? (And why don't you have to teach whatever powers Ruby's for ... in loop to teach it?) That seems to be like saying that before you can teach `main = putStrLn "Hello World"` as a Haskell hello world program, you need to go into the theoretical grounding for monads.
Re: Programming Languages Have Social Mores Not Idioms
#74Re: Programming Languages Have Social Mores Not Idioms
#75Earlier quoted context omitted.
Ruby for-loops have unusual scoping of loop variables, and if you're not familiar with this it can prove to be a source of bugs. I was bitten by this some years ago when I was first learning Ruby, and it took me a while to track down the problem. An "each" block has the scoping you'd expect, and is more consistent with the rest of the Ruby looping constructs (like select/filter or collect/map). It's not a huge deal,…
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.
The pedantic answer is the code block following the for is not parsed as or represented as a code block internally. You don't need the "do" but Ruby slurps it up to play nice. Only block semantics were fixed, but those for constructs like while, until, for, or loop remain the same as they do not introduce new scope.
Re: Programming Languages Have Social Mores Not Idioms
#76I have no particular opinion on the "what's right for beginners" part of the article. Regarding the rest, I'd add that these constructs serve as idioms in a general sense, as well as serving as social mores as described in the post. I would add that they have a third, related use (and are an example of another language construct): a shibboleth. Using these constructs indicate that you are part of the group, and (perhaps more importantly) that you've read the docs/canonical material [books, seminal posts] that the group considers important. Whether you consider this a good idea (I do, but with the understanding that it is imperfect and comes with caveats/should only be considered a starting point) likely depends on perspective on such things, but I think it's valuable to understand it.
Re: Programming Languages Have Social Mores Not Idioms
#77Re: Programming Languages Have Social Mores Not Idioms
#78You 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.
Re: Programming Languages Have Social Mores Not Idioms
#79The article views only a single definition of "idiom", ignoring several that actually define a "social more".
The useful content of the article is overshadowed by the vainglorious hyperbole.
Re: Programming Languages Have Social Mores Not Idioms
#80Earlier quoted context omitted.
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…
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 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.