Programming Languages Have Social Mores Not Idioms

I'd argue that using .each is a better choice in both of the most common cases of people wanting to learn ruby. The novice who's learning his first language will probably benefit by being taught early what it's considered the correct way to do a task. A novice can learn other "styles" later, but as a teacher you want to plant the seed in the students brain that .each is the shiznitz. In contrast an experienced programmer will probably come with for loops deeply lodged in his brain. Therefore it's also beneficial to challenge that prelearned behavior to establish the use of patters that are considered "more correct".

A novice needs to learn the most practical and correct way to do things. An experienced developer needs to learn to transpose his current knowledge to a new syntax. Both benefit from being taught the most common or correct syntaxes and patterns.

Right. Also, people should learn to swim by first dipping their tippy toes in a bathtub.

For starters, you do realize that the author/troll of the article is Zed Shaw right?

The fact that you can read a piece of code doesn't mean that you understand it. The whole point of teaching how to program is to actually get the student to learn what is actually going on, not just get them to a point where they can give a half assed explanation that really doesn't teach a thing. Repeating the line of code with extra words to convey meaning most certainly does not make it a valid explanation.

And then you come along with a list of "responses" to the concepts outlined in the article, out of which you don't even actually understand half of, and completely destroy your initial argument because of it. You complain that Zed is a troll because you can actually read the code easily, when the whole topic of his is actually wether you can understand it. It's a completely different game. You basically just proved Zed right. The problem with teaching .each first according to Zed is that since you don't understand even half of what is going on, you just do things blindly because you've grown to predict the behavior you expect from a specific piece of code.

For dessert I'm gonna "troll" a little bit. 1) If I should know variables, arrays, function calls, blocks passed to function calls (which includes an arbitrary comment about BASIC and goto statements), and scope, before I start coding then how the hell am I supposed to learn those very basic concepts? I mean according to you I shouldn't be coding right? 2) If you really don't grasp the concepts you say you don't understand in the list, you probably don't program for a living and/or have not had to actually teach any programming concepts besides the very basics. If this is the case, I'd argue that you still have a long way to go before actually having the experience to compare both "teaching orders" being compared here. 3) You give me the impression of a guy that has only done a bunch of jQuery and perhaps a Rails tutorial or two... AMIRITE?

I'm sorry if this comes off like a lengthy angry diatribe (rest assured it's not my intention), but you tried to sound knowledgeable and ended up putting your own foot in your mouth. My mother once told me to only open my mouth if I know what I'm talking about. That my friend is my advice for you.

I think Zed is conflating two things, here.

I think that "idiomatic" is correct, as applied to the behavior of programmers broadly. Groups will fall into using the language in particular ways to indicate things that aren't expressly encoded in the language spec. This will frequently happen along language lines but can also happen within a company or a project.

I think that some communities, in particular the Ruby and Python communities, additionally have strong social mores against writing non-idiomatic code.

> 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 life, but I can take the quoted example and tweak it to do something else without ever worrying what mixins are supposed to mean within the Ruby landscape. Proof:

    arr = [1, 2, 3]
    sum = 0
    arr.each { |elem| sum += elem }
    puts sum

    6

http://codepad.org/x5roEPvS

Isn't it nice that I just invented reduce semantics out of something that ostensibly is only a map?