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...
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 :-)
And mine did physics. We got "aether".