A friend pointed out the following quote from the blog post linked above.
I'm not sure how this stereotype got instilled in me, but I'm slightly embarrassed to admit that I was surprised to discover how little math is involved in day-to-day programming, especially for a web developer. A command of the written word is far more important. Intelligent, clearly-articulated prose is probably the most significant goal for both writers and programmers alike.
The math I do regularly is much more similar to the logic truth table exercises I learned in ninth grade than the complex algorithms you hear mentioned so frequently by programmers. Knowing whether an evaluation is true, false, or nil and how my programming language specifically treats each state is the extent of the "math" I do regularly. Occasionally I've had to calculate discounts or sales tax, but that's less mathematical than managing a cash register at a restaurant.
Besides, computers are way better at math than you are anyway. By learning to program, you'll learn to let them handle it for you.Now there is clearly some truth in this quote. I haven't felt the need to pull out a trigonometric or calculus equation during my short professional programming career. Unless I start doing something geometry related I might never do so. Command of natural language is probably the most important skill anyone can develop. The rest of the blog post is truthful as well.
But I don't agree that with the subtext of the quote that math class stopped being useful at ninth grade or that math programmers do regularly isn't complex.
I apply college level discrete mathematics and logic coursework to my programming everyday. Do I break out the formal notation? Sometimes, but unfortunately not usually. However, just because I use informal notation (pseudo code) or work out the problem in my head doesn't mean I didn't do any math. It just means I didn't properly show my work.
I think the mathematical logic I use is fairly complex and took a fair amount of time to obtain my current level of mastery. Set operations and data transformations in singular instances are well within the purview of laymen. Chaining multiple instances of both is something that takes some practice. You may not understand the formalities and rigor, but you do develop a feel for discrete mathematics and logic as a programmer.
You could argue that set operations and data transformations can be abstracted away. That the remaining model is simple, no complex math required. I'd say you were fundamentally wrong.
Abstractions are a tool to manage complexity, not reduce it. Complexity of a problem is constant with respect to static requirements. The complexity of the solution may change, but the required inputs and outputs remain the same.
If I have 1,000 set operations required to come to a desired result (output), it is decidedly more complex than a program which requires only one. Even if I abstract the 1,000 down to only a handful at any time complexity remains. Logic is not constrained to individual IF blocks or JOINS. It is the entire sets of possible input transformed into the entire sets of possible outputs that define the program. Your program may give intermediary output in the duration, you may have abstractions to conceptualize layers or components of the system, but fundamentally you are operating on a state machine at there beginning and an end (or cycle).
That is not to say that abstractions don't have a place in every programmer's toolbelt. It just happens they do because they are a powerful application of discrete mathematics and/or logic. For example, chunking a large set operation into manageable pieces is discrete mathematics.
Example: Login
((E U P) ^ R) ^ S = A
((Email Union Password) Intersect Users) Intersect Session = Authenticated Session
Authenticated Session is an abstraction. This abstraction will be used later in other set operations, probably in and on other abstractions. Together they will form a complex mathematical construct, even if you never think about them that way.
Example2: Login with additional abstraction
E U P = C
Email Union Password = Credentials
(C ^ R) ^ S = A
(Credentials Intersect Users) Intersect Session = Authenticated Session
The complexity of the problem has not changed (mapping of inputs to outputs), but the additional abstraction allows us to mange the complexity.
I hope the above is suitably demonstrative of applied discrete mathematics in programming. I would think most programmers could have arrived at the solutions by intuition, that is to say do it in their head or by instinct. I'd argue this is because they are very good at discrete mathematics.
The point of my argument is that my formal education in computer science placed an emphasis on discrete mathematics and logic, which are true mathematic disciplines. While I do not employ the rigor or formality, the concepts are very useful in my work.
My other point is that I use these types of complex math *all the time* in programming, even when I do not explicitly show my work. Don't sell yourself short as mathematician if you are a programmer.