Poor, Poor Child. You have no idea.

What is programming? It is the art of starting with very simple primitives, then rigorously building up slightly more complicated primitives, then building another layer on top of that, until eventually you get to a level where you can do actual work. It is staggering how far we get on how few primitives; it is incredibly educational to read what opcodes a processor actually implements. (Even better, make sure you read just the modern subset.) I mean, it pretty much just has "move this here", "add this", "multiply this", "divide this", and "if this thingy is 0 jump there". Yes, I know there's a few more, but the point is that it definitely doesn't have an opcode that downloads a webpage. It is staggering the subtle ways in which these things can interact.

It is absolutely possible in both the mathematical and programming cases to do "real work" without having the understanding of things that I refer to in my previous paragraphs. A web programmer does not constantly sit and do logic proofs, an accountant does not constantly refer to number theory throughout their day. Of course this is fine for the accountant, who is not expected to do original work in the field of accounting. (It is rather discouraged, in fact.) So of course it's OK for an accountant to have a very tool-like understanding of numbers. Are you, the programmer, expected to do no original work in the field of computing, such that you don't need to understand computing deeply? It may be so. Such jobs exist. But watch out, that means you're one library acquisition away from not having a job anymore! (And if you can't be replaced by a library, you're doing original work of some kind. Most programmers are.)

Look back at my first two paragraphs, where I have obviously drawn parallels. The real value of mathematics for a programmer is not that the programmer is likely to be sitting there doing matrices all day long, or even worrying much about logic problems, and they certainly aren't going to be sitting around all day doing sums. What mathematics provides is a clean place to learn the relationships I talk about, how we build the large concepts from the small concepts, and provides a playground where you can have that famous all-but-100% certainty that mathematicians like to go on about (justifiably so).

This is great practice for programming anything beyond a trivial project, where, if you have a clue, you will probably be starting with building up some reliable primitives, and then trying to build bigger things out of them. Bad programmers just start slopping concepts together with glue and just pour on more glue when they get in trouble, and produce what can only be described as, well, big piles of glue with no underlying order. A programmer who has become skilled in mathematics has at least a chance of producing something that is not merely a big pile of glue, and can have characteristics in their program that are characteristics that a big pile of glue can't have.

It is possible to come to this understanding without passing through formal mathematics, but it is much harder, because the world of programming is ultimately the world of engineering, and it is much harder to see these patterns. They are there, but they are obscured by the dirtyness of the real world.

That the mathematics may have an independent use is gravy; even if they were somehow otherwise worthless but programming was somehow unchanged (not really possible, but go with me here for the sake of argument) it would still be a worthwhile study. There are few better ways a programmer can spend their time than to become familiar with mathematics. Without the understanding of programming I outline above, regardless of which path you take to get there, your skillset will plateau, the maximum size or complexity of a system you can build without it coming apart will top out noticeably sooner than those who do have this understanding, and there will be things that remain forever a mystery to you. (Like how those large programs really work.)

'At this point in the book, I was originally going to present a BSP-based renderer, to complement the BSP compiler I presented in the previous chapter. What changed my plans was the considerable amount of mail about 3-D math that I’ve gotten in recent months. In every case, the writer has bemoaned his/her lack of expertise with 3-D math, and has asked what books about 3-D math I’d recommend, and how else he/she could learn more.

That’s a commendable attitude, but the truth is, there’s not all that much to 3-D math, at least not when it comes to the sort of polygon-based, realtime 3-D that’s done on PCs. You really need only two basic math tools beyond simple arithmetic: dot products and cross products, and really mostly just the former. My friend Chris Hecker points out that this is an oversimplification; he notes that lots more math-related stuff, like BSP trees, graphs, discrete math for edge stepping, and affine and perspective texture mappings, goes into a production-quality game. While that’s surely true, dot and cross products, together with matrix math and perspective projection, constitute the bulk of what most people are asking about when they inquire about “3-D math,” and, as we’ll see, are key tools for a lot of useful 3-D operations.'

(Michael Abrash, "Graphics Programming Black Book Special Edition")

Of course, this is the guy who said "Computer Science is no more about computers than astronomy is about telescopes." And while I believe I understand his point he was trying to make, I have much higher respect for a person who still likes to get their hands dirty (still actually spends significant time programming computers) rather than just dealing with abstract theory, algorithms, analysis, etc. Yes, I know that Dijkstra knew how to program (and did so, extensively, especially earlier in his career). But this is the guy who never owned his own computer -- even after personal computers became commonplace. That, coupled with the above comment about BASIC (and other comments I've read from him like it) make him come across as kind of an elitist -- like programming is beneath him or something.

Perhaps my take is wrong, and it very well could be. But I will say this. If Dijkstra was still alive and well, and you put him, Guy Steele, and Don Knuth in a room and asked me to pick two of the three to spend the day with, Dijkstra would be the one left out in the cold.