Ah, you just have to do it differently. You can't approach an enterprise problem with "real math"; real math is usually pretty brittle in practice, in the sense that the way the axiomatic systems tend to get set up you can ram the slightest deviation from them through to prove anything, thus breaking the system wide open. Practical programming does need to be more robust than that. Even Haskell requires unsafePerformIO and while end users should not use it, some important libraries certainly do. Even algorithms work tends to be not very useful.
On the other hand, the way in which you think of mathematical entities can be very important and useful, particularly in thinking of things in terms of constraints and preconditions and the resulting guarantees the code can make. Again, not in a flat-out "code proof" sense, but as a way of approaching the code. This has allowed me to write some surprisingly capable code in a multi-team setting by carefully considering the minimal requirements I can impose on the other teams to get a desired result, then making sure I enforce those requirements carefully (since I am in a language where I can't do it with a type system), and then on those basic promises build another layer of the system that is the thing I am actually working on. If I came at this with a hacky hacky chop chop approach it would fail... just as the previous effort did, ahem.
Also, in programming as in math, a thing is what it does, profoundly. This can take a long time to come to grips with. A typical programming entity "is" quite a bit more than your typical math entity, though, for better and for worse.
Preconditions, postconditions, and constraints also make great testing fodder, by which I mean, they make great practical testing fodder. Writing code in practice is a lot easier if you have some assurance that those things are actually true.
I don't necessarily even sit down and sketch this all out, again, because being too rigid causes your rigid assumptions to break, but this stuff is always in the back of my head, and it will get you quite far once you master it....
... and I say that in general. edw519 I wouldn't care to second guess how you're doing things at this point. :)
