No, the relationship between programming and mathematics is much deeper than that. In particular, it's not a relationship to the sort of mathematics you are thinking of--not the sort that you would use to solve a concrete problem or apply to physics or cooking.
Rather, the relationship is between what a program is and the very foundations of mathematics--formal logic. In particular, a programming language is a formal system exactly the same way a logic is a formal system. A mathematical proof is really the same sort of object as a computer program. It just turns out that the goals behind the two are different, so the rules of the formal system (either a logic or a programming language) behave very differently. But, at a high level, it's the same idea.
In fact, the way we ascribe semantics to programs and programming languages is analogous to how we can reason about proofs and logics. As a rough comparison, denotational semantics are like model theory and operational semantics are (sort of) like proof theory.
That said, for the most part, this relationship to mathematics is actually orthogonal to the sort of math you would use in writing a program. Linear algebra, geometry, group theory and so on are great for applications but not what I was talking about. Instead, the mathematics I was alluding to only comes out when you get sufficiently "meta" and start writing programs that operate on other programs--static analysis, verification and so on.
I'm not sure what you mean by "abstract tool", but programming is just as much an abstract tool as mathematics. The only difference is that we have some handy hardware for realizing the former.
When people program, they (usually) don't do math. And that's it.
The fact that you can view a programming language as a formal system, and the fact that computer programs can be viewed as mathematical proofs of mostly totally uninteresting propositions, doesn't magically turn programmers into mathematicians, just as the fact that the brain can be viewed as a chemical and physical system doesn't turn every thought into a chemical experiment, and each thinking person into a chemist.
It depends on what you mean by "do math". Both a proof and a program are just syntactic manipulations following a particular set of rules. The exact rules differ, but the underlying system doesn't.
Proving something in a low-level way--just following inference rules--and executing a program are basically the same things. This is abundantly clear if you formally study operational semantics, but even people who haven't still think operationally. Of course, nobody thinks purely operationally, but then again, practising mathematicians also rely on some poorly defined "intuition".
I never claimed this makes programmers mathematicians. It doesn't. Both fiddle around with formal systems, but the goals and the actual practice differ enough to make the two fairly distinct. But they're still related and we still use the same tools to analyze both: automated theorem provers, type theory, Curry-Howard...
The fact that I can bring advancements from formal logic to bear on analyzing programming languages and the fact that I can bring advancements from programming languages to analyze proofs means this is no mere "philosophical mumbo-jumbo". This includes all sorts of things you probably think completely removed from mathematics, like verifying properties of drivers or automated debugging.
Not only is it a deep relationship to think about, it's one we regularly exploit. Even if most programmers do not acknowledge it, it exists. Really, you're saying more about the state of programmers' education than anything else.
Besides, you never really made much of a point. You made a statement and a poor analogy in its support and accused me of "abuse of language", but never said anything substantial.
If the question of the poll was "My son eats carrots, what level of piano-playing does it equal to?", would you then say that eating carrots and playing the piano are fundamentally the same, because they are both reducible to physical laws and are just manifestation of different kinds of brain activity?
We all get it, and we all agree - programs can be viewed as a subset of mathematics. Every CS undergrad knows this. It is conceptually misguided to view this piece of information as revealing anything deep about what programmers do, just as it is conceptually misguided to view our ability to reduce both fishing and singing to brain activity (or to reduce everything to the laws of physics) as saying anything deep about what fishermen do. It doesn't became any less misguided simply because examples exist where math can be directly applied to programming, and vice versa.
It is philosophical mumbo-jumbo because you are taking two activities with clearly distinct meaning in everyday language, and instead of simply acknowledging that we can invent a new meaning for them under which they are the same, you instead convince yourself that this new invented meaning is the only fundamentally correct one (or somehow "deeper"), and that it also has the power to show that the 'everyday' meaning is wrong. But you are not showing anything about things we already know - you are simply presenting new, different ways of looking at them, that bear little relevance to the question at hand (A circle is topologically equivalent to a square. Does it mean that our 'old' preconceptions of difference between circles and squares are now wrong?).
The activity of doing mathematics, as those words are used in everyday language, is different from the activity of programming, even if in some senses (perhaps in more than one) they can be viewed as the same. The activity of running is different from the activity of fishing, even though they can be reduced to similar building blocks.
I do not object to the mathematical connections you present, I object to the philosophical interpretation you give to them.
Quick comment: I think people are emphasizing too much the 'logic' of mathematics, over its content. Mathematics is NOT about rigorous thinking and logical patterns (unless of course you study logic). It is much freer, pattern-based, and intuitionistic than that. It just so happens that rigorous/logical argumentation is the best way to communicate mathematics.
In this sense, programming is much more algorithmic, and hence I would argue, not particularly like math (the content) at all.
> When people program, they (usually) don't do math. And that's it.
I disagree. Whenever you implement an algorithm, you build a proof of correctness in your mind. If you reasoned about your program and are convinced that it handles all corner cases properly, then it would only be a formality to write this proof down. If you can't easily do that, then you can't possibly be certain that your program has no bugs.
In practice, you don't bother with this kind of thing unless you are writing extremely complex algorithms, of course, but that doesn't change the underlying principle.
Algorithms researchers may be employing the mathematics of computing depending upon the particular subject and scope of study. That body of non-CS academics (mathematicians, physical scientists, and engineers) who use mathematics daily as a primary component of their research are doing math when they write programs--but not necessarily the mathematics of computing.
Almost everybody else who writes programs isn't thinking in terms of mathematics, be it of computing or any other thing. Asking "what level of mathematics is this equivalent to" is therefore kind of a nonsense question--it has no real answer, because it implies there's a legitimate comparison to be made when there isn't.
I would like to jump in here and agree you. You can program some really cool stuff with a very minimal knowledge of math.
Anything beyond understanding some basic Algebra and Geometry concepts isn't required in order to program.
Most of the stuff (at least that I have run into) is just organizing data into a visual (like a report or graph) that will allow someone to make informed decisions. This only requires basic math (averages, percentages). If you can filter data, perform basic math functions on that data, spit it back out onto a report or graph then you can program for the majority of business needs.
The only time advance mathematics would be needed is if you are coding for scientists/mathematicians that want to apply advanced math to their data.
Rather, the relationship is between what a program is and the very foundations of mathematics--formal logic. In particular, a programming language is a formal system exactly the same way a logic is a formal system. A mathematical proof is really the same sort of object as a computer program. It just turns out that the goals behind the two are different, so the rules of the formal system (either a logic or a programming language) behave very differently. But, at a high level, it's the same idea.
In fact, the way we ascribe semantics to programs and programming languages is analogous to how we can reason about proofs and logics. As a rough comparison, denotational semantics are like model theory and operational semantics are (sort of) like proof theory.
That said, for the most part, this relationship to mathematics is actually orthogonal to the sort of math you would use in writing a program. Linear algebra, geometry, group theory and so on are great for applications but not what I was talking about. Instead, the mathematics I was alluding to only comes out when you get sufficiently "meta" and start writing programs that operate on other programs--static analysis, verification and so on.
I'm not sure what you mean by "abstract tool", but programming is just as much an abstract tool as mathematics. The only difference is that we have some handy hardware for realizing the former.