Wade Johnson on programming idioms.

A lot of what he says relates very clearly to the motivation behind this
that David Black and I are giving at OSCON in July. New
speakers of Ruby-as-a-second-language often feverishly attempt to force-fit
Ruby into being a syntactically different copy of whatever their
"native" language is. An oft-cited example from the Ruby world is
static vs. dynamic typing (RubyTypesAndClasses),
but it definitely doesn’t end there.

It’s a lot easier to learn a new programming language than it is to
learn a new spoken/written language. It may be for this reason that, when
learning a new spoken language, we tend to come with humility, but when
learning a new programming language, the attitude of the learner is usually
a lot less humble. So, new users of a language assume that they already
know the one true way to express programming constructs, and the only task
at hand is to learn how to syntactictally convert their thoughts into the
new language.

There are exceptions in each camp, of course. An Indian friend of mine
described a college professor who refused to learn idiomatic English and
would constantly use direct translations of colloquial Malayalam phrases in
class. His favorite, used when students were bugging him about something,
was (emphatically) "Don’t want—Don’t want. Climbing
on my head!" In Malayalam, this phrase means something and has
probably evolved based on a combination of factors, including how easily it
flows from the tongue. In English, it’s just strange sounding
nonsense. Since programs actually have to work (i.e. there is a
fast-feedback validation that happens when we write a program), programmers
will sometimes go to great lengths, building elaborate frameworks to
attempt to make a new language behave like their "native"

Wade (is it "Wade"?) talks about idioms as being singular items
that can be learned, like patterns or tricks. You learn one, you over-use
it, you start to use it correctly, and then you learn another. I know
he’s presenting a simplified look at the process, but I think
it’s important to separate the learning of a language’s idioms
from learning what is idiomatic in that language. Learning of idioms is
about knowledge transfer whereas learning about "idiomatic"
requires a thought process change. I think of the former as being a step
toward the latter.

On an unrelated note, Wade makes an interesting point about what I would
call "dissonance" (see SeasideDissonance
and MFA:Tension).

   Idiom can also serve as a warning. An unusual or advanced idiom
   should tell the reader that he is entering dangerous territory. This
   is a message that it's time to pay close attention.

On another unrelated note, I think we must define both "simple"
and "expressive" differently:

  The simpler the language, the quicker you get to the end of this cycle.
  But, a simpler language is not as expressive. So, you find yourself doing
  more work than should be necessary. A more expressive language takes
  longer to learn, but it's easier to pass on subtle shades of meaning to
  the maintenance programmer (possibly yourself).

I think of Scheme as being both extremely simple and extremely expressive,
while I think of a language like Java as being very complex but not very
expressive. I would be more likely to say: "But, a more rigid language
is not as expressive." And to me, rigidity is much more likely to
result from complexity than simplicity.