Programming Languages Have Social Mores Not Idioms

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.

'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.

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.

Consider this snippet from natural language:

Paul: "Hey nice jacket, looks great on you"

Linus: "Word"

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.

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".

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.

If you use a for loop in situations where the variables used by the loop are 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 aren't needed outside the loop, you pollute the code with unnecessary ambiguity.

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:

  x = 5
  (1..3).each do |x|
    x = 99
  end

  puts x #=> will print 5

>You aren't creating programmers, you're creating good little Rubyists.

You should be creating good Rubyists, if you're using Ruby to teach programming.