Why do most programmers work so hard at pretending that they’re not doing math?

The rest of us working on our sites, platforms, apps and what-have-you usually only see anything resembling math when dealing with things like UI and Interaction models, or typically soft-math areas like rating systems and segmentation.

Possibly inflammatory, but perhaps a better question would be: why do most programmers work so hard at pretending they're engineers?

But then the Electrical Engineering guys come and conquer, then CS evolve closer to EE than to Math.

And these days, well... your boss always look at you and say that does not want to now about math or performance, he want to know about accomplished deadlines and nice UIs.

Of course, I say this as somebody who likes Haskell where the programmers work really hard at pretending to be mathematicians :)

However, even when I'm writing in other language, I think about things in terms of math. Additionally, my CS courses so far have all been heavily influenced by math, except for systems that was much more heavily influenced by EE.

So, at least for me, programming is very much like math. Just shinier. And I do think that more math--or at least mathematical thinking--would help most programmers.

However, the rant against testing is just silly. Tests are not a replacement for math--they augment it. We need tests because, at heart, CS is an engineering discipline: math is just a tool we use very pervasively.

Haskell is one of the more extreme typed functional languages, and yet Haskell programmers are very amenable to testing. In fact, Haskell programmers tend to go above and beyond normal testing: we use property-based testing (QuickCheck). Instead of just having unit tests, we actually generate random tests.

Besides, lets look at physics: they have great mathematical models. However, as soon as you actually apply physics--basically engineering--you need to test everything extensively. There is a reason we have exhaustive crash tests, after all.

So: math is good for programmers. Tests are also good for programmers. The two cannot replace each other.

Another way to look at it is that we’re making progress, but with lots of false starts, like most progress. Hearsay and taste are what happen when people are working with imperfect information. Probably not even Knuth has perfect information about all the studies and models that might be relevant to any nontrivial project.

The author’s point seems to be not that programmers should understand the math behind their work, but that they should do work that’s more like math. It’s true this would mean fewer bugs. But there are a lot of problems that people in the real world would rather have mostly solved by a slightly buggy dynamic program with mutation and state hiding than not solved by a formally proven program.

A lot of programming is stuff like simple CRUD web apps. I’d rather do that in Python than Haskell for the moment. If the author wants to argue that Haskell could be made friendlier without giving up its advantages, that’s an essay I would welcome.