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

[goldsquare.livejournal.com]

No fair.

He used words of more than one syllable. :-)

[gyzki.livejournal.com]

As someone who spends his days bringing definitions of "associative" and "commutative" down to a third-grade level of understanding, I smile at the thought that sort of fancy-pants terminology is too obscure for the average programmer. But providing practical examples is certainly a good and helpful thing.

[jducoeur]

Well, it's important to remember that functional programming tends to use these terms at the airy-theoretical level, not the arithmetic level -- it's all about creating new *kinds* of objects. So instead of applying these concepts to numbers, you're creating new things that are kind of (but not exactly) like numbers, and describing how these principles relate to those objects.

The results can be pretty unintuitive, especially when you get into the theoretical definitions of things like "identity", which are horribly important for really understanding how to use powerful tools like monads. Hence, the desire to reduce the amount of jargon required in order to enter the field...

[gyzki.livejournal.com]

The results can be pretty unintuitive, especially when you get into the theoretical definitions of things like "identity", which are horribly important for really understanding how to use powerful tools like monads. Hence, the desire to reduce the amount of jargon required in order to enter the field...

My father did his dissertation on Leibniz, so I grew up with 'monad' as a household word. Not everyone can be so lucky :-)

[calygrey.livejournal.com]

My father did his dissertation on Leibniz, so I grew up with 'monad' as a household word.

And mine did physics. We got "aether".

[jducoeur]

Whereas I grew up with "COBOL" and "Fortran" -- decent starting points, but arguably much more obsolete ideas than aether at this point...

[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.)