Replace fancy-pants terminology

[jducoeur]

Engineers -- especially those who are on the edges of functional programming -- may appreciate this posting from Guy Steele. In it, he argues that the functional-programming community has picked up a lot of jargon from the math world like "associative", "commutative" and "identity", but while those concepts are ferociously important, the terminology mostly just gets in the way of the average programmer.

While I don't love his specific strawman proposals (eg, replace "Commutative" with "OrderDoesn'tMatter"), I think he's basically onto something here. Spelling out what these concepts *mean* in practice a little more clearly (and his table of examples is wonderfully clear) would probably lower a major barrier to entry into functional programming...

Comments

[ladymacgregor.livejournal.com]

As someone who spends *her* days "translating" developerese into plain language, I have found that removing jargon and having clear, specific, and understandable (if longer) definitions helps *everyone* in the department. Developers tossing around the jargon may *think* that they are talking about the same thing, but if you listen closely and then pin them down in some cases, it turns out they are talking about completely separate concepts (which always startles them). And in our company, I am starting to think that the English-as-a-second-language developers outnumber the "native speakers." (Not just Indian, either - we have Turkish, Moroccan, several Russians, a couple of Chinese, and just hired a Frenchman.)