This is contrary to what most logicians think: "Programs are Proofs", <a href="http://homepages.inf.ed.ac.uk/wadler/papers/frege/frege.pdf" rel="nofollow">http://homepages.inf.ed.ac.uk/wadler/papers/frege/frege.pdf</a>, a paper by Phillip Wadler, seems to outline the case pretty conclusively.<p>Or maybe, as my 5th-grader says, "There's school math, and then there's fun math". Programs are not arithmetic, that's true. I think Ms Mei's view of "math" is impoverished, and this blog post is proof.
100% agree with this. Anecdotally, I know a lot of people who would be great at programming but they'd never consider it because of their pre-conceived notion that they'd have to be good at math first.<p>I've never been particularly good at math, and learned enough to get by in my CS theory classes. I hardly ever use math to program, unless the problem is specifically math-based or geometry-based. To me, programming is communication and organization.
For me, programming is math because nowhere else in my experience do I have the degree of certainty that I have in programming. The article seems to think that calculus is the archetype of mathematics, but integers are mathematical objects as well. As natural numbers, 1+1=2 - always. Just like programming. Except the natural numbers never fail due to a failed disk drive, power supply, fan, electrostatic discharge, etc, HOWEVER, those externalities are never a part of programming (just as sleep deprivation is never part of mathematics) unless you're explicitly modelling failures, and in that case, you're making a mathematical model of a system that includes failures. Outside of programming and mathematics, entities and operations on them are usually much less reliable.<p>When you program, you manipulate a mathematical object, not the physical embodiment of that object. If you're dealing with the physical embodiment, you're a chip designer. Even at the level of FPGAs, your dealing more with the mathematical model of the device than with the details of the device itself.
There are different types of programming, ranging from directly applied theory, for example scientific modelling, to solving everyday problems, for example creating an interface to a health system. In the best case multidisciplinary teams will work together to solve problems to support many perspectives. Pure math is sometimes necessary, but in many cases it's not, and the projected requirement to be a math expert to participate in formulating new digital connections is a very harmful force causing digital illiteracy and wasted opportunities for participation.