Posted
by
Soulskill
on Friday July 18, 2014 @05:37PM
from the i-before-e-except-SyntaxError: dept.

An anonymous reader writes: There's often debate amongst modern programmers about how much math a professional developer should know, and to what extent programming is math. Learning to program is often viewed as being on a spectrum between learning math and learning spoken/written languages. But in a new article, Jeremy Kun argues that the spectrum should be formulated another way: Human language -> Mathematics -> Programming. "Having studied all three subjects, I'd argue that mathematics falls between language and programming on the hierarchy of rigor. ... [T]he hierarchy of abstraction is the exact reverse, with programming being the most concrete and language being the most abstract. Perhaps this is why people consider mathematics a bridge between human language and programming. Because it allows you to express more formal ideas in a more concrete language, without making you worry about such specific hardware details like whether your integers are capped at 32 bits or 64. Indeed, if you think that the core of programming is expressing abstract ideas in a concrete language, then this makes a lot of sense. This is precisely why learning mathematics is 'better' at helping you learn the kind of abstract thinking you want for programming than language. Because mathematics is closer to programming on the hierarchy. It helps even more that mathematics and programming readily share topics."

It highly depends on what you do. If you work mostly with the common database applications, basic math is enough for you and it is unlikely that you will ever need anything above Calculus or even Calculus.

On the other hand, if you work with RF you will most likely need a lot of math. If you work with high level optimization algorithms you will need Abstract Algebra. If you work with Geolocation you will need a fair amount of high level Geometry, specially Non Euclidean ones.

So in the end the answer is: Higher Math is not necessary in all fields of programming but it is certainly very necessary in many.

Studying computer science requires a fair amount of math to understand why some algorithms are more efficient than others rather than just accepting that they are. And, it can be a great help in working out the storage and IO requirements of a program. How much math you need to be a working programmer depends, as you point out, on what branch of programming you specialize in. Personally, I've always considered programming to be more a branch of logic than one of math.

As a guy with two masters in math who knows 15 languages... I also disagree. There are some languages that are mathematical (like Haskell) but most programming has more in common with cooking (sequencing the application of resources) than math.

In the end, I've always concluded the same, every year this topic comes up (it is just about annual here). I don't want you to know calculus because you'll actually use calculus on the job (though I have an O(N) vs O(log(N)) question on my interviews that you'd better be able to answer).

I want you to know/pass calculus because by the time you've worked that hard at that level of proofs, you've mastered *variable control*. In each level of math, you don't get out of the class having mastered it. You get out of the class having mastered the year that came before it. When you can pass calculus, you have *mastered* functions and analytic geometry (I hire for UI work). Passing those two the year before showed you mastered variable manipulation and proofs in Algebra 2 before it.

So no, you don't *need* calculus on the job, but you need everything below it, and the best proof that you've *mastered* them (not just taken them, but mastered them) is that you've passed a calculus class.

I went for years keeping my math and my programming separate. Often programming involves little more math than x++. But then I really buckled down and learned a pile of math which I now pile into my programming. Interestingly enough when I try to show my algorithms to other programmers they say, "I forgot all that math 1 day after exams." But these algorithms often are cutting thousands of lines of code away and result in answers that are instant instead of a more iterative approach that could take minutes or much longer.

The math that I am referring to is all pretty basic year 1 or 2 stuff. Basic Discrete, basic calculus, etc.

A "programmer" can be someone who spends two days putting together a complex Excel macro (poorly), or someone who designs an information systems architecture for a significant enterprise. These are VERY different activities.

On top of that, I'll say that approximately 85% of people doing programming aren't really competent. Compare how often software crashes vs how often cars fail in such a way that they crash themselves. So you have to specify, are you talking about MOST programming, or competent programming? Most programming isn't done competently.

Well-designed and larger software projects require a thorough understanding of a large set of rules, both knowing what the rules are, and understanding WHY the rules are as they are, and when to apply which rules in order to move forward. In that sense, it's very much like math. Also like math, one wrong decision can lead you down a path of futility, from whence reversing course is time-consuming.

TFA is really about the human mind. We understand patterns as different forms of language, music is the most basic and universal, it lights up all areas of the brain, then you have spoken language built on top of musical patterns, then along comes symbolism in the form of writing and icons, math is our most recent and most precise form of natural language [youtube.com].

The take home message is, expose your kids to maths [youtube.com] without boring them to death.