Wade Johnson on programming idioms.

A lot of what he says relates very clearly to the motivation behind this talk 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" language.

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.