[8ren]

IMHO the difficult part is seeing the commonality of those edge cases. That requires firstly knowing about the edge cases, and secondly seeing the problem (the commonality of those cases). The final step is a solution, which is where the maths comes in (or might).

Anecdotally, it seems fairly common that maths is independently re-invented by people applying it - famously for relativity, IIRC. That's because the maths guys don't actually know about the applications.

It's a truism for our industry that if a new approach really is significantly better (eg. x10) in practice, it will be adopted. You don't need to convince people; you just beat them. OTOH, there's a common wish to over-automate: to spend a week saving a second, and then it turns out to not handle the very next case. So, some people don't like to use frameworks because they are too constricting (don't handle all the cases in practice); and some (Alan Kay) even say if you can build your own infrastructure, you should.

Mathematical ideas usually only work on their own assumptions - a difficult part is matching those assumptions to an application. Though maybe this isn't a problem for the generics example.

There's also incidental practical issues, like the need to ship, then of back-compatibility, resulting in a current Java implementation that can't express List<Circle|Rect> (you need an explicit Shape interface/superclass). Although *ML has proper algebraic data types, does C# do it properly? I don't know.

[silentbicycle]

> That's because the maths guys don't actually know about the applications.

That's often a big part of it: Someone who isn't a day-to-day user of something sees an issue in it and recognizes that it could be done in a cleaner way, but explains the solution in their own terms rather than in the local language.