For some odd reason, whenever you ask whether math is important to programming, there is a strong correlation between the depth of a programmer's mathematical training and his belief in its importance.
There can be many explanations for this, but the simplest is that when you have a tool in your tool chest, you tend to use it, and when you use a tool, you see opportunities to use it everywhere. Whereas if you don't have a tool, you don't see the opportunities it affords, so you don't know what you're missing.
Even if my conjecture is true, this doesn't mean that mathematics is more important than some other experience a programmer might bring to their career, so I am not suggesting that the author is wrong when suggesting it isn't important. Perhaps it's useful but less important than some other skills.
I'm not a mathematician, so I don't know, it's all blub to me.
There also is a huge difference between the two groups with respect to what they think math actually is. Many lay persons do not know that logic and discrete mathematics are math.
The moment you reason about the control flow in your program, or even when you figure out that a for i=1 to 10 loop will terminate, you are doing math.
If the problems aren't hard, the math isn't hard, and you can even get away with some trial and error math (aka debugging). However, for harder problems such as a file system's source code, an encryption library, or a multi-threaded program, tweaking the code until it 'seems to be robust' is not the way to go. For those, you need good maths skills.
my grandfather worked on AT&T System UNIX with what was basically an 8th grade education.
if you read "Secrets of Consulting" there's a few rules that my grandfather laid out; one of them is "If you're doing math above elementary level, you're doing it wrong".
I've done many very powerful things with that rule.
Indeed. He has had a massive influence on the profession and on me personally. Secrets of Consulting is a great book that every software person should read. It's not just about consulting. It's much more useful than that, and so entertaining that it's surprising how profound it is.
However, most likely indrora's grandfather was someone else. First, Jerry Weinberg has a Ph.D.; that's a little beyond 8th grade. I also remember hearing him talk about majoring in physics as an undergrad because computer science didn't exist yet. And I've never heard of him working on Unix. He was an IBM guy after all.
I doubt that Weinberg ever objected to using advanced math to solve technical problems, including programming problems, when appropriate. What he has objected to is complex models and metrics that purport to quantify human behavior when in reality they're not measuring anything significant. Weinberg regards this as a form of escapism (my word not his), a way of hiding behind technicality to avoid facing human situations. He wrote a whole book, in fact, called First Order Measurement arguing that simple measurements -- including just plain personal observation -- are the best way to monitor complex systems, such as a software project.
Weinberg was a great humanizer of the software industry. You can see his influence on Agile (the good parts, not the slick parts, which I heard him denounce as early as 2004). I think it took courage for him to talk about Virginia Satir in software circles - or would have, if software people had any idea what Satir did.
I probably knew indrora's grandfather, for though I worked for IBM, I consulted with Bell Labs and other parts of ATT for many years, in IBM and as an independent. In fact, I was twice the Bell Labs Distinguished Lecturer, touring all the labs--helping out with C and Unix.
As for math, it was one of my majors as an undergraduate, and I am a member of Pi Mu Epsilon, and have published a number of mathematical papers, though not recently.
But, I'm a hacker at heart, always have been, always will be. I use math only when it's helpful to solve problems. That's true of any tool I use. Why? Because the higher the math or esoteric the tool, the more you diminish the number of other people who can understand what you're doing.
Indeed, that's why I'm now writing fiction that helps people grasp a few mathematical and software concepts. For instance, my mystery novel, "Freshman Murders," has a team of math geniuses as the "detective." And I still write techie stuff, when I have something to say.
It's perhaps true that if you're doing arithmetic and calculations above the elementary level it's a sign that there's something wrong. But if you observe and prove that two operations commute and that doing them the other way round allows various advantages such as check-pointing or extraction of common sub-expression computation, it's slightly less clear.
An anecdote. I once noticed in a web programming context that someone was doing the same calculations over and over. The way the code was organised made it necessary, results couldn't be cached, nor could they be precomputed.
I showed that a sub-class of the operations were commutative (that took several pages, and then a 2 day meeting with the chief designer) which allowed some of the loop/function-call orderings to be reversed. Compute time went down by a factor of 100, and scalability was achieved.
The problem reminded me of some stuff I'd done in ring theory classes, and had something in common with the idea of groups acting on a topological space. The math wasn't actually directly useful - it just brought it all into focus and gave me a way to think.
Basic math is all you need to program, but many times, the cool things you can do with programming will need strong math. For example, just working with mapping data, I need to be able to think pretty extensively about functions for changing coordinate systems, figuring out which tiles I need for a specific zoom level, etc. Of course the actual math itself is basic trig, the abstract concepts are much more difficult, and I'd argue those are math related.
Extending the mapping analogy, I built a 3D terrain system with a simple mesh overlay, and drew a 3D route inside of the system. I had to map the route onto the terrain, and to do that I needed to understand a good amount of vector manipulation (cross products amongst others). Maybe this is 8th grade math in Russia, but it certainly isn't taught until College here in the US.
So, yes writing a program itself doesn't require math, but many of the cool domains require math.
Just because someone has no formal training in math, and doesn't recognize that what they're doing could be called math, (or strategically refuses to apply the word 'math' to what they do, for sound pedagogical reasons) doesn't mean that they aren't doing math.
The cult of the Ph.D. is strong, but you don't actually need some kind of license to think logically about abstract concepts, anymore than a musician needs a formal music education or a cat needs a formal gymnastics education.
In my experience as someone with a lot of math in my toolkit, many, perhaps most, of the people I work with end up wishing they had similar skills. It's not just me saying math is useful, it's the people who have seen it used.
I agree with that, but it's hard to believe something is important if you have no concept of it. (People know that "math" exists, but until they've studied specific areas, they probably will have never been exposed to those concepts or ways of thinking.)
What year? What experience do you have? What math have you done? What are you interested in?
Number theory.
+ What is modulo arithmetic?
+ If p is prime and 1 <= a < p, why is a^(p-1)-1 a multiple of p?
+ If a prime is conguent to 3 mod 4, why is it never the sum of two squares?
+ If a prime is conguent to 1 mod 4, why is it always the sum of two squares?
Topology
+ Find examples of why path-wise connected is stronger than "not disconnected".
+ Show that in 2D if you consider parallel lines to converge at infinity, and that they all converge to the same point, then what you have is a 2-sphere
+ Show that in 2D if you consider parallel lines to converge at infinity, and that non-parallel lines converge to different points at infinity, then what you have is a Moebius strip with its edge glued to a disk. (projective plane, or RP2)
Analysis
+ Understand why the sum 1/2 + 1/3 + 1/4 + 1/5 + 1/6 + ... diverges (and what that means)
+ Understand why the sum 1/2 + 1/4 + 1/8 + 1/16 + ... converges, what that means, and what it converges to.
++ Note: most undergraduate mathematicians get this wrong.
There's a bunch of stuff, and this is all straight from the top of my head. It's not necessarily good advice, but they are a few things I found interesting when I was 12 or 13.
Math--the fun kind, at least--consists entirely of thinking about abstract logical objects. A lot of programming is also this. They usually don't line up, except in cases like Haskell's type system, but the brainpower you develop in one is useful for the other.
True. But when people write "programmers should know math" articles, what they're almost always actually saying is "I took linear algebra in college, therefore all programmers should have taken linear algebra in college", not "programmers should be able to engage in abstract logical reasoning".
My own take on this is that many programmers like to believe their chosen subset of the field (in the case of "learn math" articles, often people who work in game development or scientific computing) is the only "real" programming, and that everyone who chooses another subset is deluded, stupid or otherwise inferior.
I agree about this correlation in general -- although personally I'm a counterexample: a degree in applied math, and a strong belief that it's not particularly important to programming.
True, in programming you need to think rigorously and abstractly, and the same's true in math. However to be a great programmer you also need systems thinking, the engineering skills to use components that don't always work as advertised, understanding of social dynamics [both how software is constructed and how it gets used], etc. etc. Math doesn't give you any of these.
So it seems to me that there are other ways to learn rigor and abstraction that are at least as good a preparation for programming as math: different branches of science, law, operations research, user experience, etc. etc.
Guido van Rossum holds a master's degree in Math and CS.
I'd say that it is common sense that mathematical talent is correlated with coding talent provided that the person receive substantial training in coding. Generally speaking, everyone is a terrible coder for the first 2 years, it doesn't matter if you are a math genius, you still need to learn how to crank out good code.
The real question is: is there extra correlation between math talent and programming talent beyond both being correlated with g, the general intelligence factor.
The importance of math in programming is directly related to the domain you are working in. The strong logic background math gives you is important for anyone who programs, but advanced concepts just don't matter that much to most programmers.
<fx: sighs and starts rant and posibly excessive claims unsupported by objective evidence>
It's not the math, it's not the advanced concepts. It's the ability to think in abstract terms, about abstract objects, rigorously sometimes, intuitively sometimes.
It's not the direct benefits. Knowing topology or analysis is unlikely ever to help you. Being able to do topology and analysis probably will, in subtle, unexpected and most often unnoticed ways.
Every single advanced athelete does progressive weight training. Why? Certainly not because they want to be able to lift weights. No, it's because of the side-effects. Similarly doing advanced math trains your mind in ways that are relevant to programming, and unobtainable elsewhere.
I won't convince people who are already convinced that math is useless, and most people who haven't done any advanced math will see that they don't appear to use it, and thereby believe that it's useless.
I agree with you generally, but how much mathematical thinking will help you still depends extremely on the kind of job you are doing.
In my experience the single thing in which mathematical thinking can help you best is going meta. When you reason about the program as the program were data. It is not a coincidence that smart people with mathematical talent wants to go meta: they love to write frameworks, new programing languages, compilers, (graphical, database) engines.
But most of the programmers have to write good old application logic (so called business logic) using languages, frameworks, engines, technologies made by other people.
I go further: most people have to use bad programming languages, programming languages which are not their choice. Most people have to maintain bad quality code created by other people.
For these tasks mathematical thinking is really secondary. You have to have other skills: very good memory, finding your way in a complex mess, etc... If you are mathematically 'smart', you will find patterns, you will be bored, you will go meta, and they need to find another guy for the mundane task.
Tool ... good. Tool with two thousand years of history behind it, very good!
However, I haven't notice a similar degree of correlation between programming and Egyptian history... Knuth was about literate programming, so maybe English literature could be good tool too.
The inverse is actually true... the deeper your mathematical training is, the more you realize how unimportant it is in most programming. The people who espouse otherwise either haven't studied enough math, or more usually, haven't done that much programming.
Well my hypothesis is that regardless of one's opinion of the value of mathematics to programming or mathematical knowledge, one is likely to advocate that a strong mathematical background correlates with opining one's given assessment of the value of mathematics to programming ;)
There can be many explanations for this, but the simplest is that when you have a tool in your tool chest, you tend to use it, and when you use a tool, you see opportunities to use it everywhere. Whereas if you don't have a tool, you don't see the opportunities it affords, so you don't know what you're missing.
Even if my conjecture is true, this doesn't mean that mathematics is more important than some other experience a programmer might bring to their career, so I am not suggesting that the author is wrong when suggesting it isn't important. Perhaps it's useful but less important than some other skills.
I'm not a mathematician, so I don't know, it's all blub to me.