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.
Saying otherwise is just an abuse of language.
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.
In this sense, programming is much more algorithmic, and hence I would argue, not particularly like math (the content) at all.
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.
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.
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.
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.
> I'm not sure there is such a difference between mathematics and an "algorithm"
This is like saying: "There isn't such a difference between neurology and physics. A brain can be viewed as a collection of cells, which in turn can be viewed as a collection of organic molecules, which in turn can be viewed as a collection of particles, and physics studies particles. So neurology = physics. Q.E.D"
But what is missing here is the realization that it is exactly our decision not to view the brain as a collection of particles which gives neurology it's meaning. The decision to view something as something else is not trivial. When you choose to view X as Y, it is no longer X you are talking about.
You wrote: "...it just may not be the kind of mathematics we usually associate with the word."
But it is precisely what we "usually associate with the word" which gives meaning to words. If in this "usual" meaning it is wrong to say that mathematics is the study of algorithms, then mathematics isn't the study of algorithms.
When we want to create new precise definitions to old words, what we are trying to do is to formulate a description that fits as best as possible our everyday use of this word. If we ended up with a definition of math that says "the analysis of everything is math", the only logical conclusion is that we did a pretty bad job.