Programming Languages Have Social Mores Not Idioms

My understanding of software engineering and computer science is that we should design with a clear mental pattern of what we need to build to get something done. This way, if there is some bug, we can trace it back in the design and not in the code. If we designed with the language in mind, then our software would be limited by the language itself. Then the bugs would just be harder to squash, because we now have to adapt our troubleshooting skills to the language and not the problem. In practice, anytime I face some bug, I just sit back and think about the design and not about the languge/syntax/idioms. It commonly takes me but a few minutes to mentally trace back the problem to the source. No debugger needed.

Zed, this is a fantastic piece, and I hope you include it as part of your books. Since you have shown to have such fine understanding of the problems begineers face, you should write a little booklet that should include things like the one mentioned here. Thank you for this post.

I'd argue that learning .each vs. normal looping has numerous benefits. First, this is the way most people loop most things in Ruby. More importantly, however, teaching .each enabled me to be more openminded towards learning "yield" and blocks.

In a way, without having learned about .each first, and coming into Ruby with my preconceptions (or no conceptions), I would have been confused. I would have been writing Ruby as if I were writing Python or C, without really understanding the benefits of writing Ruby as Ruby ought to be written.

To me it seems like there are two consequences.

1) It's a huge burden on the beginner to be effectively aware of all the possibilities of doing things (like looping) in a language, and why one should be used where. In general, when a beginner picks up a language, he should be doing stuff and recognizing the trade-offs of what he's doing. Thus, he culminates critical awareness through choices and reflection of those choices.

I just can't imagine myself learning Python and hearing about doing things in a hundred different non-Pythonic ways. Unless I were to do it one way, and then later discover of my own accord that there is another way I can do it which has its associated cost/benefits.

2) If these "social mores" are indoctrination, and indoctrination is taboo, what if beginners stop writing .each loops? What if Python programmers start writing "magical" code? etc.

Wouldn't these Python programmers fragment the community and alienate/isolated themselves from a community which has firmly established conventions (for good reasons).

Either way, I love that this point has been raised. I've been looking into Ruby especially, and am always fascinated about how different the conventions and styles are.

Actually, the singular is "mos".

These are all relevant questions when determining if it is a function or not.

Just the simple fact that loop control is determined by a boolean and requires state implies that for isn't really a function.

For what it's worth, I think Zed has a point. If you're trying to introduce a broad array of concepts to a new a programmer, going with a mapping method associated with an iterable is kind of complicated if you want to explain the whole shebang.

Compare map from Haskell, Lisp, Python etc with each. In each of those languages, you only need to introduce:

1) Named values (as variables, or not) 2) Functions 3) Lists 4) The idea that a function can take a function as an argument

You do need all the additional stuff for each that he mentions.

Similarly, in languages that make higher order functions more difficult, and have implicit state, for is an easier thing to explain.