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

Calling it an "extremely valid concern" is understating it. The dilemma is that programmers have many, many roads to follow if they want to improve their product, all of them discrete, deep fields in their own. Math is great, and certainly studying it will expand your mind...but so will studying engineering practices, statistics (which yes, is a kind of math, but not as theoretical as the kind the OP is advocating for), user interface design, and knowledge domains (medicine, legal, earth sciences, etc.)...all of which, as far as most programmers can tell, will yield concrete rewards much more easily than will mastering higher level mathematics.

- EECS circuit design is based on a conceit that gives chips a speed limit

- as a result, chips aren't getting much faster and that multi-cores are happening instead

- parallel programming will become more and more essential to make a buck as a programmer

- imperative languages aren't great for parallel programming due to mutable variables

- functional languages are better for parallel programming due to immutable variables

- functional languages are a lot closer to math concepts than imperative languages

- uh-oh

So for me it's been a fun few months of stumbling through self-directed study in stats, probability, and math. Bayesian probability from some articles by Yudkowsky. Fast, clumsy review of 0th-order, 1st-order, and zfc set theory. Anki decks out the wazoo. Now I'm plodding through Learn You A Haskell.

I would like to work more with actual mathematical proofs but I'm finding that tough to get into myself. It was fun paging through metamath for a few days, though.

Heh heh. Never thought about it like that. Amazing write-up, btw. As somebody who dabbled in both CS & Math, I'd say the cultures are vastly different. You can spend years, decades even, just teaching undergrad calc courses while having barely 1-2 papers to your name, and yet you'd be considered a legitimate mathematician & get paid & all that. I know scores of math professors who are in that category. With CS, if you don't have productive output in a week, you are just idling & companies will fire you. CS academia isn't a whole lot different...the paper output is a lot more, though much of it is backed by programatic machinery.

As a consequence, a standardized notation/syntax has developed out of sheer pragmatic necessity. Everybody knows what you mean when you say its a hash, or a bst, or an lfsr, or a trie or a monad ( you wish :) Well atleast some of these are standard concepts across all pgmming languages.

With math, you can labor for years in some obscure field ( heh heh a mathematician will kill for that pun!) in which less than ten people know what you mean. At a conference, Hilbert was supposed to have gotten up and asked a speaker "What do you mean by a Hilbert space?". That should tell you something. The syntax is remarkably nonstandard & even simple things like edges, nodes, edge weight, graph correspondingly become arcs, vertices, payload, network depending on where the literature originates from. When I studied a few math papers in grad school, I had a lurking suspicion the author was going out of his way to obscure his thought process & result. With CS papers, you atleast get straightforward pseudocode & you can run off to your favorite language whether php or haskell & give it a shot. There are math texts out there where you pick up one of them, you feel like a complete fool, you pick up the other, you instantly get the point, and they are both talking about the same exact thing !! artin vs dummit & foote vs herstein comes to mind...i got 1000% more out of herstein than the other two.

I agree with the author that in the absence of standard math terminology, I'm afraid programers struggling to learn advanced math just learn bits & pieces necessary to get their job done & move back to fighting their daily battles with git rebase & jira tickets.

Indeed, the opposite problems are familiar to a beginning programmer when they aren’t in a group of active programmers. Why is it that people give up or don’t enjoy programming? Is it because they have a hard time getting honest help from rudely abrupt moderators on help websites like stackoverflow? Is it because often when one wants to learn the basics, they are overloaded with the entirety of the documentation and the overwhelming resources of the internet and all its inhabitants? Is it because compiler errors are nonsensically exact, but very rarely helpful? Is it because when you learn it alone, you are bombarded with contradicting messages about what you should be doing and why (and often for the wrong reasons)?

The difference is that the CS community recognizes that these are problems; every single thing he's complaining about are open problems being taken seriously and attacked from multiple directions, and there is hope for serious improvement in the coming decades. Anyone who thinks rude snobs, bad documentation, or useless compiler errors are a beneficial is rightly ridiculed as a smug weenie or accused of having an ulterior motive.

By contrast, mathematicians are defensive and complacent about their arcane, non-inclusive notation and communication: "At this point you might see all of this as my complaining, but in truth I’m saying this notational flexibility and ambiguity is a benefit." Look at the litany of problems he just presented. Consider the fact that mathematics is not the only complicated subject that requires complicated, flexible, and rigorous notation. It just isn't credible that the shitty state of mathematical notation is either necessary or unavoidable. The occasional counterexample, where someone with a good understanding of a subject presents it in full rigor without resorting to the usual obfuscation, is a hint of what could be.

If your publications cannot be read without an expert interpreter, they are defective. Hypertext has been around for decades, if you're going to invent your own ad-hoc (or even standardized!) syntax to solve a problem your readers have a right that you document the meaning of your notation.

This may be good advice if you want to get into pure mathematics, but huge parts of maths are not pure.

Applied mathematics is very relevant for programmers - especially game programmers. It's not a sin to sacrifice mathematical rigour for the sake of discovery.

It doesn't even have to be a direct map (e.g. actual implementations of calculus or such). Just understanding various bits and pieces in granular detail can help you get precise and testable quantitative ideas for problems.

For instance, a while ago I wanted to implement a kind of smooth up-and-down motion for an object in my game. Almost immediately I thought of equations of this form:

(y position) = (some amplitude)* sin((some frequency)*(time)) + (some value to denote the origin)

This is a first step for some fairly interesting up-and-down motion - the rest is all a matter of finding suitable constants.

Similar things come to mind when you want to move an object smoothly to another position along a line, with a decreasing speed:

position = ((position you want to move to) - (current position)) / (some constant) + (some minimum speed)

This stuff just flashes before your mind if you've done plenty of physics (or 'mechanics' in mathematics) before. What's more, you'll know countless other ways of increasing the complexity of your equations without having to do much trial & error hacking (except to find things like constants and such).

For games, I'm convinced that there's still an incredibly huge variety of mathematical behaviour that has yet to be harnessed for the implementation of actual game mechanics. (Games usually just use some game engine's implementation of only some parts of classical mechanics, for instance.)

Never underestimate the relevance of applied mathematics to real-world programming, even though it doesn't really occupy a spectacularly prominent position in CS-focused courses.

"If I add sin(x) to both sides of the equation, then I can use such-and-such identity which makes this equal foo."

If you don't make the correct mental leap, then you get completely stuck and it's really easy to give up.

I agree there is value in learning how to read math notation, so there is a valid point in there somewhere.

This isn't unique to mathematics; it's the reason it's hard to scale the number of programmers working together on a Lisp codebase. Each programmer writes their own notation (macros), and ends up down their own rabbit-hole of a sub-language that nobody else can immediately understand.

There is a bit of a continuum, though. Using Excel effectively involves a smidgen of programming, similar to how "using math" effectively really means using other peoples' theorems to "prove" things, very informally, about your own domain. Maybe that's why people are more likely to get confused between "using" math and "doing" math.

First of all, let's acknowledge that many (the great majority of?) programmers have little or no use for math, and know it, and are correct. That's totally fine. I think danso's comment captures this well, with references to UI design, domain knowledge, engineering practices, etc, and dxbydt similarly mentions "git rebase and jira tickets". So let's assume we're restricting ourselves to programmers who do have a use for math (and hopefully know it).

FIRST PROBLEM

TFA's introductory claim is apparently that there are programmers who say "math is useful, I want to use it, I don't want to read or write proofs", and that this is ludicrous. It's absolutely not ludicrous.

Yes, a working mathematician's job is to explore and understand the space of mathematics, and yes, that is inextricably bound up in proof. And I would suggest that learning more about math proof is a soul-enriching use of anyone's time (in the same broad vein as learning Latin). But techniques of calculation are one of the valuable outputs of mathematicians, and it is reasonable and effective for a person with a task to say "I would like to have more powerful techniques of calculation, and I don't want to learn proofs".

For example. Certainly it is possible to learn how to do Gaussian elimination, and use it to solve systems of linear equations, to good effect, without being able to prove that elementary row operations preserve the system. Maybe it helps? Maybe it doesn't? If you want to invent a new technique, I imagine that in that case being able to prove the correctness of the existing technique probably helps a great deal. But what's unreasonable about the person who says "I have these equations, I need to find the values (if any) of these variables here that make all the equations true, and I'm too busy to learn any proofs today (and too busy to write any proofs ever)"?

For a simpler example, we used arithmetic just fine before ZFC.

SECOND PROBLEM

Maybe this is actually two problems, intertwined. And maybe both of these problems are quibbling.

Primus, he says "Mathematics is cousin to programming in terms of the learning curve, obscure culture, and the amount of time one spends confused". I think this is highly questionable. Mathematics is far harder and more baroque than programming, not least because as a discipline it's nearly one hundred times older.

Secundus, after acknowledging the insanely annoying tendency of math papers to make up their own notation without ever defining it, he claims that the non-mathematician's confusion is comparable to the non-programmer's confusion at for(;;);. No, it's not comparable. The math case is hard because someone failed to tell you what you need to know, and no one wrote it down anywhere. The for-loop is only hard if you did the opposite: failed to read what was actually written down (e.g. in K&R) and took someone's word for it that the standard and general form of the for-loop is for(int i=0;i<LIMIT;i++){ /do stuff with i/ }

My claim here is that the learning math - even just the calculation techniques - is genuinely inherently hard. Partly that's because it's so overwhelmingly useful that if it wasn't, we'd already know it; clever students know more calculation technique by age 15 than most professional programmers know about programming. But on the other hand it's also contingently hard, because mathematicians aren't generally very interested (nor incented) to export their product so that outsiders can make use of it. Which I guess isn't so terrible; once someone else labours mightily to learn all that very-hard math, you can hire her at an exorbitant rate to make use of the calculating techniques she has learned. Or if you want to get that benefit without paying the exorbitant rates to outsource the math, you can roll up your own sleeves. Good luck!

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.

In other words, "no math is needed" and "you need proofs" are probably both true. There's some realm of programming in which no math is needed, ever. And then there's other programming that requires lots of math. But the math required, might be linear algebra in some cases and some other specific branch of math in another area. This fact is a just a reflection of the fact that "programming" is an extremely wide area. There are some realms of programming, where the "programming" aspect of it is virtually subsidiary to the math. The programming is just automating or systemizing some math which is the real work is taking place.

So, my take away from seeing this discussion and similar comments so many times is that everyone can agree that math is an enriching subject. However, from the standpoint of its relationship with your programming, going really deep into one particular area of math without a clear idea of if/how it's going to help you accomplish something previously unattainable is probably not the best use of your time.

Regrettably, it's out of print, and you have a choice of paying upwards of $138.50 (abebooks.com) for a used copy of a book of jokes, or finding the pirated pdf I once encountered in a search (I've no idea how complete that was).

Reading the first chapter preview at Amazon, I already see the need for a human to explain something to me:

Two sentences from the book [1]: "A possible relation between sets, more elementary than belonging, is equality." and "Two sets are equal if and only if they have the same elements". These already seem to be contradicting each other -- how can equality be more basic than belonging if the former is defined in terms of the latter.

While I agree with OP on the difficulty I face when learning advanced mathematics (notation, generally tacitly assumed by the authors), one thing that also bugs me is use of human language (!) as a part of the proofs. How do I know that the proof is correct and is not impacted by something fundamental about the language itself? Merely via inclusion of a human language in the proof, a lot more axioms "may" have been included than what meets the eye. Probably not, but I often find it hard to convince myself of this.

[1] www.amazon.com/Naive-Theory-Undergraduate-Texts-Mathematics/dp/0387900926

If anyone is interested in learning a bit of mathematics to structure programs (for real-world usage, even!) feel free to let me know what you'd be looking for. I'd love to help!

http://hhgproject.org/entries/bistromathics.html

Clearly, Douglas Adams spent a lot of time in Bistros, as the second review on this site echoes his sentiments about the odd behaviour of waiters and nonabsolute numbers such as time of arrival:

http://www.yelp.co.uk/biz/giannis-italian-bistro-san-ramon

Background: I have a BS in EE from IIT Bombay, An MS in Applied Math from USC and an almost PhD(everything but thesis) in Pure Math.

I also loved teaching math as a TA and was able to teach engineers multivariable calculus and differential equations so that they lost their fear of it.

But for the last 20 years have been in the database business. I am very enthusiastically returning to math in the form of data science in the last year.

I find that especially today it is necessary for math to be made accessible without having to prove theorems - that's for professional mathematicians.

Programmers use hardware often without knowing diddly-squat about semiconductors. And that's just fine if you don't want to or need to. We drive cars, use mobile phones and all sorts of machinery without needing to know anything about internal combustion or the CDMA algorithms or even how theory of relativity figures into GPS.

I think the insistence on setting a high bar for people to learn/use/apply math is unnecessary mystification and obscurantism.

Math is beautiful, useful and powerful. If you know math you should be wanting to simplify it's teaching and instruction, thinking hard about making it useful for the non-mathematician and also making it easier to access in a breadth-first fashion rather than the depth-first fashion in which it is currently practiced.

I know many people, engineers and mathematicians who believe that simplification is "dumbing down". I disagree vehemently.

Today if you are a programmer and want to learn math I have a few of suggestions

a) If you want to apply it in engineering take a couple of classes on Coursera/Udacity - it will be a slow an steady way to re-activate your math neurons (it's also insurance against Alzheimers to keep learning new and hard stuff).

b) Learn some statistics, learn to use R. (Coursera again)

c) Learn some linear algebra, minimal, then learn MATLAB (Andrew Ng's Machine Learning class on Coursera or a similar one by AbuMustaffa (sp?) of Caltech)

d) If you absolutely don't want to learn a new language then look at Machine Learning by Marsden which uses Python and then pick up NumPy/SciPy and look up the exciting stuff that's happening with the IPython Notebook.

e) If your focus is on pure CS the take the Algorithms track(s) by Roughgarden (Stanford) or Sedgewick (Princeton) on Coursera

This way you dont have the notation issues - R has a syntax, MATLAB has a syntax just learn it. Python hopefully is note even an issue.

Start using your math brain a little at a time - absolutely no proofs required - and THEN once you see the beauty and want to learn more and want to learn why, THEN dig deeper with the fundamentals. If you don't that's fine too - use it, put its power to use and become a better developer and engineer. Math is not trivial but it's not as hard as it's made out to be. There's way too much noise in the channel.

Good luck.

(feel free connect with me on twitter if you want to get more help (@nitin))