The word "idiom" has two different senses. First, there's the sense that the author is discussing. In this sense idioms are expressions whose meanings aren't derivable from the meanings of their parts (linguists call this "non-compositionality"). The other sense of "idiom" simply means "an expression that characterizes <i>idiomatic</i> speech.<p>Now "idiomatic" also has two senses. First, it can mean "having to do with idioms". Second, it can mean "peculiar to a particular group, individual or style". (See <a href="http://www.merriam-webster.com/dictionary/idiomatic" rel="nofollow">http://www.merriam-webster.com/dictionary/idiomatic</a>)<p>So, I think when people speak of idioms regarding programming languages they're using the second of the above senses. While this sense might be characterized as having to do with social mores, I don't think it's a misuse of the word "idiom". People don't mean to say that .each statements are non-compositional in the way that "kick the bucket" is. Indeed, given that programming languages have formal grammars/semantics it's hard to imagine what non-compositionality would be at all (though I'm sure any good Perl programmer could probably give some examples!)
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 the power and expressiveness of ruby really come into play. For example:<p><pre><code> users.select(&:meets_some_critera?).each(&:update!)
</code></pre>
You could totally do that in a for each loop if you wanted. But it isn't really composable. While this works for the basic update...<p><pre><code> for user in users do
user.update! if user.meets_criteria?
end
</code></pre>
... what if you wanted to then sum up the new account balances? In the first example, you'd just chain on a couple more enumerable methods:<p><pre><code> users.select(&:meets_some_critera?).each(&:update!)
.map(&:account_balance).inject(&:+)
</code></pre>
With the for each construct you'd have to pass in an accumulator variable and keep track of whether to sum or not. While you certainly can do it in a for each construct, I'd argue that you'd be missing out on what makes ruby, ruby. And getting beginners in that more functional(ish) frame of mind sooner rather than later is a very good thing.<p>--edited a few times for formatting/clarity
I'm sorry, but this post is absolutely ridiculous in every way.<p>I think most programmers understand what is meant when people say a programming "idiom", just like most people understand that it's OK to call small representative computer graphics "icons" even though they're not physical religious symbols.<p>Words gain new meanings in new contexts, that's how language evolves. Complaining about it after-the-fact is just stupid. Nobody's going to start calling these "social mores" because of this article.<p>And as to why ".each" is a horrible looping construct, the only justification is that it's harder to teach. Well, sure, if you're teaching someone programming for the first time it's probably better to start with "for". That doesn't mean ".each" isn't superior for experienced programmers, though. The author doesn't address <i>any</i> of the advantages to ".each".
Before I learned Ruby, I knew C, Obj-C, C++, Java...all languages that have and use "for" extensively. Coming to Ruby and learning "each" was an eye opening experience for me. Suddenly, the whole notion of iterators become clear to me. (While I had used them in the past, I had only marginally understood them.) After using "each" for a while, I came to realize that I was programming in a functional style without even knowing it.<p>Earlier today I read through Rich Hickey's posts explaining reducers and actually used them to get crazy performance gains from some Clojure code I was writing...but I highly doubt I would've gotten there without Ruby's "each".<p>I've seen Zed argue on this point before, and I've always been dubious of his "concern". The one point he makes here, though, that makes me side with him is that "for" is easier to teach than "each". Yes. A hundred times: yes!<p>The point I will disagree with him on is that "for" and "each" are interchangeable. Semantically, yes. Performance-wise, probably. But stylistically, "each" is a gateway drug to functional programming, and that should <i>not</i> be taken for granted.<p>(<i>Edit</i>: Where this all breaks down, and where I think Zed is experiencing frustration, is that while <i>some</i> people might have had a good reason for using "each", over time it <i>became</i> a social more. Now people teach and even enforce the use of "each" without being able to explain why. That doesn't mean one should avoid teaching "use each, not for", but it does mean that one should go and find out <i>why</i>.)<p>Start with "for". Teach "each".<p>...then go learn Clojure because <i>hot DAMN</i> reducers are going to revolutionize the way we program (but that's another topic for another day).
I think Zed misses the point of idioms both in programming languages and in natural language.<p>Consider this snippet from natural language:<p>Paul: "Hey nice jacket, looks great on you"<p>Linus: "Word"<p>Linus used an idiom to articulate his sentiment. Why? Because the idiom, if used around someone who understands it, offers little uncertainty about the meaning while also being concise.<p>Linus could have said, "Why thank you. You really didn't have to say that. I appreciate the compliment but I'd rather not spend a lot of time discussing my jacket".<p>The idiom was useful because it added clarity, both by reducing the excess information going over the communication channel and also by clarifying the intent.<p>If you use a for loop in situations where the variables used by the loop <i>are</i> needed outside the loop, then there is no reduction in clarity b/c of the choice of a for loop. However, if you use a for loop when the variables used by the loop <i>aren't</i> needed outside the loop, you pollute the code with unnecessary ambiguity.<p>Ruby 1.8 had this problem with block variable scope and it was fixed in 1.9. Now in 1.9 you can write code like this:<p><pre><code> x = 5
(1..3).each do |x|
x = 99
end
puts x #=> will print 5</code></pre>
Outside of the last point about the each method not being a good first exposure to looping, the article was mainly just debating the definition of idiom. That's irrelevant because definitions of English words are overloaded in different fields such as CS all the time.<p>Nevertheless, this use of <i>idiom</i> does seem consistent with its normal usage. In the context of natural languages, an idiom <i>can</i> mean a phrase of arbitrary origin that has come to have a specific meaning in specific dialects (this is referred to as an idiomatic expression), but the adjective idiomatic can also be used in the sense of "what sounds most conventional to a native speaker" [1]. Likewise, in programming languages, I think of something as being "idiomatic" if it follows either formal conventions [2] or is a commonly used construct.<p>As for the author's negative opinion of having idioms in a language, I'd imagine most programmers advocate conventions in order to keep code somewhat consistent across programmers. If you didn't have them at all and if every programmer used different constructs to do the same thing, programmers wouldn't be able to use pattern recognition to read others' code and all code written by multiple people would be even harder to decipher than poorly written Perl since there would be infinitely many ways to do it. TWBIMWTDI? :)<p>[1] I don't want to say what sounds "right" (hence my use of "conventional") since that would necessitate a lengthy discussion about grammatical prescriptivism, but just note that colloquial expressions like "the people who I gave the ball to" can be considered just as idiomatic (under this definition) as formal expressions like "the persons to whom I gave the ball", even if prescriptivists would define only the latter as "correct".<p>[2] Unlike natural languages whose syntax is naturally occurring, prescriptivism in programming languages makes sense since they're invented by humans to make writers, readers, and/or revisers of code more productive.
Programming isn't just about giving instructions to a computer, it's an act of communication to anyone who will read your code down the road. Having a consistent set of rules is an important part of that communication. Just as a style guide for a natural language can help readability, good conventions can make code more readable. Python goes as far as defining an official style guide (PEP-8)
This is a troll, or the author completely lacks any
pedagogical skills. The offending (sic) code:<p><pre><code> arr.each { |elem| puts elem }
</code></pre>
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, function, block, array. Done.<p>The prosecution charges:<p>> Variables<p>Basic elementary concept, if you don't get this, you should not be coding yet.<p>> Arrays<p>Basic elementary concept, if you don't get this, you should not be coding yet.<p>> Enumerable<p>I have no idea what enumerable is, but I can read the code just fine.<p>> Inheritance<p>I have no idea what inheritance means in this context, but I can read the code just fine.<p>> Mixins vs. Multiple Inheritance<p>For lack of better words, wtf is the author talking about?<p>> Message passing and dispatch.<p>Ditto wtf.<p>> Function calls.<p>Basic elementary concept, if you don't get this, you should not be coding yet.<p>> Blocks passed to function calls.<p>Arguably basic elementary concept, in spite of the long tradition of Basic teaching us otherwise. But then Basic taught us GOTO is a good idea, fortunately we've got past that idea eons ago.<p>> Yielding variables to blocks.<p>I have no idea what yielding is or how it helps in this context. Still I can understand the code just fine.<p>> Scope, specifically for blocks.<p>Scope is a subcategory of variables, if you don't get scoping then you don't get variables, see blurb on "Variables" section.
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?<p>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.<p>This only requires you to teach variables, arrays, the if statement, goto/jumps and objects with their methods.<p>And frankly it being ruby, I don't think it's bad at all to teach objects and their methods, before teaching iterations.<p>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?<p>An each method can be explained with a simple recursive function, no need to dive into hocus pocus CPU details.
From the OP:<p><i>I'm saying teaching [idioms] as if they are the universal truths is bad. I teach them too, but I teach them as if they are just arbitrary bullshit you need in order to code with other people who have been indoctrinated.</i><p>While I agree with the general argument Zed's making, I think it's important not to create a false dichotomy where an idiom is either a universal truth or little more than arbitrary bullshit.<p>There are legitimate reasons to prefer constructs like "each" over for loops and it would be a mistake to let that get lost in the noise.
I don't know where on earth he got "By definition an idiom is something you remove from good clean writing," which is obviously not true (edit: and itself contains an idiom, "good clean", which you can recognize as an idiom simply by reversing the two words), but I think he's right about the important thing, programming language mores. It's crazy odd how what appear as purely technical constructs become nuclei for all kinds of tribal and emotional behavior.<p>Here's my explanation: the human brain is an identity machine. Apply it intensely to anything over time and you can't help but identify with what you're doing and how. As soon as identity is involved the complete human package kicks in, including emotion and tribalism (banding together with those of like identity in opposition to those of unlike identity). Opposite ways of doing things begin to seem like threats, criticism evokes defensive feelings and so on. If you think you don't function this way, try paying closer attention.
I'm curious. Zed Shaw writes that forcing beginners to learn these things without having them critically approach the alternatives is equivalent to indoctrination. IE. Python coders "must" write explicit code (although they have the means to write something more implicit/magical), Ruby "must" write .each (when they can do for, while, etc).<p>To me it seems like there are two consequences.<p>1) It's a huge burden on the beginner to be effectively aware of <i>all</i> 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.<p>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.<p>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.<p>Wouldn't these Python programmers fragment the community and alienate/isolated themselves from a community which has firmly established conventions (for good reasons).<p>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.
There is an important reason why one would use #each instead of a for loop: encapsulation.<p>Looping over a collection object requires some knowledge of its internal state (length in the case of a simple linear structure like Array). In most cases where we use for loops, that information isn't really relevant. There is no need to expose it to the outside world and break encapsulation.<p>Being consistent in using #each helps when you have complex/custom collection objects where iteration can't be done through a simple for loop. The object might not want to expose its underlying collection and hence can't provide a suitable way to use a for loop on it. Or maybe the collection object has dead elements that it wants to skip and so on. There are any number of reasons to hide the implementation details of the iteration from the external world.<p>Given this and since Ruby has a powerful block syntax, favouring #each fanatically over for loops, IMHO, is a good thing.<p>EDIT: I'm also guilty of accusing LRTH with the 'not idiomatic enough' charge in a blogpost I recently wrote for Ruby beginners at <a href="http://www.jasimabasheer.com/posts/meta_introduction_to_ruby.html" rel="nofollow">http://www.jasimabasheer.com/posts/meta_introduction_to_ruby...</a>.
I've never really understood the Ruby community's attitude toward for loops. I learned Ruby as my first language and read many blog posts and instructional books that told me to absolutely avoid the for loop. Of course when I started to learn JavaScript and C, I had to figure out their versions of the for loop then, and it made me start wondering why there had been such opposition to something that seemed to be a normal part of the Ruby language. I can understand "idioms" if they have some benefit over non-idiomatic versions, but in a language like Ruby that supposedly embraces TMTOWDI, I can't, for the life of me, figure out why .each is always best.
I 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.
I think most of us use idiom in programming to mean 'a form of expression natural to a language, person, or group of people: he had a feeling for phrase and idiom.'<p>The key is 'natural to a language'. Some writers assume they're helping teach a programming language by teaching what the community regards as the most 'natural' solution to a given problem in order to avoid bad habits. In this sense, 'idiomatic' meaning 'using, containing, or denoting expressions that are natural to a native speaker' is an extremely useful phrase because it implies that a native speaker is an experienced programmer who understands both how to use the language effectively and how the wider community uses it.<p>'Mores' implies the use of a custom by a social group that may or may not be useful. However, in this case, 'each' is an idiomatic use of the Ruby language. The fact it's awkward to teach what makes 'each' work doesn't detract from the fact that it's widely regarded as a better way to iterate over enumerable collections. To me, the fact it draws on such a large portion of the language may indicate that those parts are actually incredibly useful, and in combination can result in succinct and expressive forms that become easy to work with after a certain amount of education.<p>The distinction between what's difficult to teach and what becomes natural after a certain amount of education is extremely interesting. I suspect accomplished Ruby programmers originally took a leap of faith and just adopted 'each' because they were told to, then later on fully appreciated the underlying implementation. That doesn't make it less idiomatic, it just makes it more difficult to teach.
<i>> In the process I've stumbled on what Rubyists call an "idiom", the use of .each to do loops instead of a for-loop. To them this is one of the most important signs that you are a real Ruby programmer. They look at this usage of one looping construct over another as some sign that you are incompetent, and haven't been properly indoctrinated into the Ruby community's ways.</i><p>As a Smalltalker, I think select/find/collect/each to be wonderful things, as they are of the same spirit as the do: collect: select: reject: methods in the Smalltalk Collection methods. That said, I find the notion of stigma attached to certain constructs to be counter-productive. In my experience, such attitudes are more about socially scoring points and vying for social dominance than they are actually about improving the community's code. However you get the functionality done is fine, so long as it's short and understandable.<p>(Such stigma attached to situations where people could use inject:into: but didn't was often counterproductive to readaibility in the Smalltalk community.)
The more languages I dip into, and the more code I write, the more I realize people tend to just overdo things with no other purpose than to make things more complex. I love simple. My approach is to design the software in my head as if it was a system of independent components. This function does X, this function does Y, here I have a loop that uses function X to get the value that function Y needs to get value A. Never do I sit down and just write code that is "idiomatic". Don't care about it. When I started learning, all I did was write very simple code. Never did I use a class, or any OOP. My code was easy to follow, readable, and could be "translated" to run in any language. And that is one very important thing that I've learned. Design and code should be easy to translate from one language to another without much hassle. One should not rely too much on some language or framework in order do something.<p>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.<p>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.
The article views only a single definition of "idiom", ignoring several that actually define a "social more".<p>The useful content of the article is overshadowed by the vainglorious hyperbole.
not following the standard idiom of a particular programming language causes people to balk because it shows how unfamiliar the author is and how little code the author has read or been exposed to in that language. Its a huge sign that even though the author may be smart there probably beginner level bugs in the code.
I think the reason why for-loops are rejected in Ruby is because of it's Smalltalk heritage.<p>In smalltalk there are no loops and no ifs... just methods that are executed on a condition. So 'each:' isn't any more complicated than a 'whileTrue:'.<p>Just take a look at this Smalltalk examples[1]:
-----
[ condition ] whileFalse: [ statements ]
[ condition ] ifTrue: [ statements ]<p>aCollection do: [ :var1 :var2 | statements ]
----<p>[1] <a href="http://www.cincomsmalltalk.com/tutorials/version7/tutorial1/vwloops1.htm" rel="nofollow">http://www.cincomsmalltalk.com/tutorials/version7/tutorial1/...</a>
I think Zed is conflating two things, here.<p>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.<p>I think that some communities, in particular the Ruby and Python communities, additionally have strong social mores against writing non-idiomatic code.
I disagree about the 'each' being a 'social more' as opposed to 'for'.<p>The most important thing you will ever learn about conditional loops is that effectively they are all shorthand for combinations of compare statements and conditional jumps in assembly. Past that really, none are more conceptually simple than any other...<p>So the analogy of 'each' being "piece of cake" to 'for' being "easy" doesn't really hold to me. Nor does the extreme list of 'concepts I'd have to teach to show someone how .each... works'. They both effectively are the same level of abstraction from 'CMP' and 'J__'.<p>As someone who learned ruby as my first real language, 'each' made a lot of sense to me. It uses fewer words and relates more closely to the english language than 'for...' to my mind. I don't want to say this is the case for everybody, and 'for...' definitely at least has one advantage (cross language use - though I'm not sure this should be of major importance in a ruby tutorial).<p>But to me this page doesn't really present a convincing argument against the teaching of 'each' before 'for...'
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".<p>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.
I always interpret "idiomatic" as "avoiding performance issues". In Python, for example, using the join method on strings is not only idiomatic, it's performant. Even if a particular idiom has no effect on performance, the worst that happens is I write idiomatic code. Not only that, but idiomatic coding allows me to write performant code without having to understand <i>why</i> it performs well. I don't know Ruby, so I can't comment on each vs for loops, but in general there's a practical, performance-based advantage to idiomatic coding.
I think perhaps the reason that these have become known as "idioms" is that in older programming languages, there really <i>are</i> idioms. For a classic example, in C we have:<p><pre><code> for (;;) {
}
</code></pre>
to mean an endless loop. This really is an idiom - to people who've "grown up" with it, it says "endless loop" as clear as day, but for everyone else it just looks odd. And C programmers who know the idiom don't tend to look down on someone who instead uses:<p><pre><code> while (1) {
}
</code></pre>
or some other form.
I don't agree as well. For loop is engrained in our brains so deeply that I think next generation of programmers should not be taught it. It took me quite some time to stop using it, even though I write C++ and it is a lot more difficult to write in functional style. Sometimes I'm just forced to use it. Most of the mainstream languages already support constructs from functional paradigm: C++11, C#, even Java got lambda functions. So, I will say no, don't teach for loops. Teach functional programming.
I agree that the .each method may not be the best looping construct to teach first and I agree that some people do get a bit over zealous about which constructs you 'should' be using.<p>I feel it's definitely a good idea to ensure the reader is introduced to the .each early though. I guess it's taken for granted now as lots of languages have added their own versions of them, however for myself, coming from a language that doesn't have blocks it's a really good way to start to understand how they work.
Why does the author insist that to teach each to a beginner he has to teach all of those concepts? Sure, to understand it fully you need to know about those things, but you can definitely get a beginner far enough along without explaining every detail.<p>Did K&R explain everything about the preprocessor with their "Hello, world!" example? Or the implications of different return codes from main(), what 'return' from a function even means, etc?
Why would you need to teach inheritance, mixins, message passing, enumerable, etc. to teach .each as a first looping construct? (And why <i>don't</i> you have to teach whatever powers Ruby's for ... in loop to teach <i>it</i>?) 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.
If you're coming in as a programming novice, "each" and "for" constructs should look equally as foreign, so you may as well teach the standard conventions. It takes longer to unlearn something, than it is to learn.<p>>You aren't creating programmers, you're creating good little Rubyists.<p>You should be creating good Rubyists, if you're using Ruby to teach programming.
Oh, oops. I was overly skeptical nearly to the end because I thought he meant a numeric for loop instead of a for-each loop. I misunderstood the entire distinction, because while there is little reason to pick .each over for-each, there are very good reasons to use <i>some kind of</i> 'each' method.
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."
Interesting distinction between idioms and mores. ( I was not aware of it.) However a difference between social mores and technical ones is, that technical mores can acquire meaning since more time is spend to optimize the preferred way.
I don't see the relevance of the style guide mentioned for the debate over how to teach beginners. When you check out a guide, it has to be assumed you are familiar with pretty much most of the syntax of your language.
.each isn't a looping construct. It is mapping function. Looping constructs allow control over the loop iteration. Mapping functions do not.<p>People probably shouldn't confuse them. Does Ruby actually have a looping function?
It seems to me as though this is not so much about removing idioms from code as using only C-family idioms in code (and even then, regressing as closely to plain C as the semantics of the language permit).
[I tried to post this as a comment, but Zed decided to delete it :/]<p>I think your comparison between for loops and .each is flawed - clearly you don't need to explain all those concepts in detail if at all. A for loop ultimately involves some level of polymorphism on the target collection, at least to the same level as required by the call to .each. I'd say that conceptually they are very similar, with both constructs having specific differentiating features.<p>Also, .each doesn't eventually become a for-loop in C code. 1/ Neither Ruby nor Python are compiled to C code, and 2/ I wouldn't expect that the respective looping constructs become a typical C for loop, it is more likely they will be implemented in the native op-code (e.g. CPython, Ruby 1.9).<p>With respect to why .each is fundamental to Ruby, we clearly see some key differences between Python and Ruby in this respect. I think the critical thing is that Ruby tends towards being a functional language while Python tends to be more imperative. We can see this clearly in the types of operations provided by Python, for example, list.reverse() in Ruby returns a copy of the list in reverse order, but in Python it reverses the list in place.<p>Using .each in Ruby code leads to shorter more concise code in contrast to the corresponding Python code. Whether you feel that you are being judged or not (in a social sense) is probably a matter of who you choose to interact with on that level (e.g. a particular developer community). Have you ever had to use non-idomatic C code? How about non-idomatic Python code? Clearly, a big issue with source code is composition (on a project level) and non-idiomatic code causes many issues in this area.<p>It is also interesting to note that non-idomatic behaviour plays a role in larger society. For example, choose the GPL and you might receive some complaints from communities that typically use MIT or BSD license. How about real life? If your friend buys you a drink and you don't play the social "ball game" (e.g. behave non-idomatically) you might have social problems in that area too.<p>I think that ultimately you are confusing a social interaction with a programming language best practice. I don't think either of these things are bad - heck, look at all the company specific coding standards for C or C++ code - but ultimately whether you choose to indoctrinate your students into a particular social circle, or teach them the best practice for a given programming language is simply a matter of perspective; and empowering your students to understand why things are the way they are, rather than simply saying this is the way we've always done things, is ultimately something I think is very important.
yeah, but it's just a social more of the programming community to describe social mores as idioms :-p<p>Thoroughly agree with the crux of the argument, though. There is too much cargo cult science wih regards to programming practice. eg don't ever use gotos, upper case reserved words in SQL, functions should be no bigger than N lines. This type of thinking cripples our critical faculties, and is to be resisted.
Please, goto/jump .. reminds me of the rant about not being able to implicitely couple two function with global variable mutation in functional programming.