Why there is no Hitchhiker’s Guide to Mathematics for Programmers

This is good advice for programmers who want to become better mathematicians. That seems to me to be distinct from wanting to be better at applying mathematics to programming problems. In the same way that wanting to be a better gardener is distinct from wanting to understand the aspects of gardening that will help you write programs relevant to that domain, with the obvious caveat that mathematics-related knowledge is relevant to a much wider range of problems people try to solve using software than gardening-related knowledge.

In school I appreciated the sorts of classes that stressed proof the most, like topology or real analysis 2, because they made me a better mathematician. When programming, I am frequently glad that I took some upper level math class, but generally for reasons unrelated to whether I've actually done mathematics in that area. For instance, I could take advantage of the equivalence of the square metric and the Manhattan metric in a 2-space (up to a 45 degree rotation of the space) regardless of whether my topology class had emphasized proofs. The attitude portrayed as absurd in the article ("I don't want to write or read proofs, just use theorems") doesn't seem that far off from one that would work pretty well. The main issue with that attitude is the belief that a large body of theorems can be understood without understanding any of their proofs. Programmers don't need to be able to write proofs that aren't extremely trivial, but people who want to apply ideas from some area of mathematics probably need to understand it in a deeper way than memorizing theorems.

>you need to get comfortable with proofs

True, but this is simply not the point of programming/CS. Back in grad school in CS, we used leiserson. Leiserson has proof of quicksort! I mean, that's fucking crazy. He mathematically derives amortized runtime of quicksort.I really loved leiserson. But even my professors hated it...they'd say, lets skip over the proof section, its not important. Nowadays people use Skeina. Skeina is like a storybook. It tells you - do this, get that, if you want to know more, read leiserson! So skeina basically punts. This is why everybody loves skeina, because no proofs. Just straight algorithms that can be translated to code. Skeina is slightly better than Numerical Recipes cookbook, in that it tells you what to do & points you to the why, but doesn't tell you the why. But math is all about why.

Now look at a typical grad math course. They love artin. artin is full of proofs. Well, show me how the direct product works out. Ok, install GAP, & bang out some 10 line script, & boom, done! No refactoring, no nice variable names, no explanation...its as opaque as it gets. You just call the function & it'll do its thing. You want to know why ? Well, that's programming, & we are mathematicians, why do you want to know those things, its some messy bullshit C code, they have this thing called data structure in programming, you have to know about pointer, reference,...dude just type the script & get back to Artin.

So each culture actively repels the other, even though they are massively co-dependent. Even department level politics are driven by that rivalry. Math depts are money losers net net. CS otoh brings in tons of dough. Guess who teaches all the difficult discrete math courses in CS ? Yeah, its the math profs! Crazy, I tell you.

I agree with you and the OP that creating a standard notation for all math is problematic. And you're right that there are conceptual difficulties behind the math that are not going to be automatically resolved by clearer communication. But a lot of the difficulties are accidents of culture.

To continue the programming language/mathematical notation allegory, you can use whatever notation you want to describe your program in a Lisp with macros. But you have to actually define what your notation means. Neglecting to provide the definition of the macros would be the equivalent of a logical argument that leaves off its premises or the state of math publications today from the perspective of the poor sap that has to read them (and the mind of the person who wrote it).

> if you don't do proofs you won't get any better at understanding mathematics

There is a vast world of mathematical understanding available to programmers who don't like proofs. I think there is some miscommunication here about what constitutes mathematics. Mathematicians tend to think of the art of proving things, whereas engineers (and programmers, and scientists) think of equations and how to solve them. I think mathematicians actually do a disservice to engineers by trying to beat them over the head with real analysis and set theory (which is why most physics and engineering departments end up having to teach their own mathematical methods courses).

The "foundational" knowledge of mathematics -- epsilons, deltas, Cantor sets, Banach spaces, etc. -- is irrelevant to almost all practitioners. Newton, Taylor, Euler, Gauss, Laplace, Bessel, Maxwell and the gang got pretty far without it. When programmers say they want to learn math, they mean they want practical knowledge: interesting functions, how to compute them, and their properties that can be applied with utility. They don't want -- or need -- to spend time poring over proofs.

It seems you're under the impression that real analysis is the foundation of mathematics (I certainly wouldn't consider Cantor sets or Banach spaces in there).

Let's say you invent a new machine learning algorithm, how can you know how well it does? If you invent an algorithm to do anything, how can you be sure it's correct? Well you can always test it some things, but if it's really a new algorithm, then you need to prove it does what you say it does in all possible cases.

It's fine and dandy if someone tells you that there is this function that you can compute and use in this way and it's the best for its purpose, but this is an extremely rare case. I believe I have mentioned this elsewhere in comments, but there is almost never a clear-cut answer in mathematics that someone can just use out of the box. It almost always involves tweaking to fit a particular application, and to really understand how to tweak an algorithm you need to understand why the algorithm works the way it does.