Replace fancy-pants terminology

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

Replace fancy-pants terminology

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