Math, Programming, and Language Learning 241
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."
Re:Your Results Will Vary (Score:5, Interesting)
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.
Re:Your Results Will Vary (Score:4, Interesting)
Re:I disagree (Score:5, Interesting)
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.
Re: Your Results Will Vary (Score:5, Interesting)
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.
The more math the better (Score:4, Interesting)
The math that I am referring to is all pretty basic year 1 or 2 stuff. Basic Discrete, basic calculus, etc.
depends. VBA is very different from systems arch (Score:5, Interesting)
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.
Re:depends. VBA is very different from systems arc (Score:4, Interesting)
The take home message is, expose your kids to maths [youtube.com] without boring them to death.