A commonality of ideas, principles and views on programming, according to which programming is essentially a mathematical activity.
The most basic observation from where we depart is that programs and software systems in general are mathematical objects. This is a matter of fact. The task of programming is the activity of constructing these mathematical objects that satisfy certain requirements, using specific languages, tools, etc. The requirements themselves are mathematical properties. The languages tools, etc, are mathematical objects. Nolens-volens we are doing a mathematical activity.
To quote EwDijkstra from his splendid http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD641.PDF (a must read for all programmers):
Just because you can use mathematics to reason about something does not imply that it is, ipso facto, a mathematical object. Mathematics is used to reason about internal combustion engines, radioactive decay and juggling patterns. Using mathematics is not doing mathematics.
The paper by EwDijkstra that you refer to is saying almost exactly this. He is saying that programmers should use mathematical techniques. They should, in essence, acquire and use the skills and techniques of the mathematician. The fact that there are so many working programmers who do not do this is evidence that programming is not math.
A collection of relevant quotes, and links is likely to follow, please contribute here.
Unfortunately we had a rather heated debate on wiki triggered by the page IsProgrammingMath, which doubted either the usefulness or the relevance or even the truthfulness of ProgrammingIsMath; it wasn't very clear what was the sense of the question.
ProgrammingIsMath is not debatable.
Yes it is debatable. Even Dijkstra says it is engineering in addition to math.
It is a matter of assumed choice for a large number of software engineers and computer scientists. ProgrammingIsMath is also the legacy of such geniuses as RobertFloyd? , EwDijkstra and many others. [insert - I sincerely doubt there are many mathematicians who would agree.] The results of this approach in ComputerScience and SoftwareEngineering are the very basis of all programming activities. Put them aside, and you won't have programming as a profession anymore. You won't have the hardware we have today, you won't have the operating systems, the compilers, the databases, you won't have anything. So much for the naysayers. And besides, debating it is like debating whether esthetic is personal. It is a view, a school of thought, not a matter of debate. We can debate if this view is useful and if it provides good results. As I mentioned above, even if we conclude that it only provides poor results or it is clearly inferior to other approaches, we can't escape the fact that we can't live without it.
There are, of course, alternative views of programming. Things like DesignPatterns, QualityWithoutaName and other kinds of views drifted away from a mathematical perspective and went closer to architecture, philosophy and other arts. Many adepts of ProgrammingIsMath [but by no means all] look them as rather fruitless enterprises. For example PeterNorvig considers DesignPatterns as the result of trying to fix poorly constructed abstraction and inadequacies of particular programming languages. The most critical voice was, of course, that of EwDijkstra.
I think it might be more accurate to say MathIsProgramming?, where "programming" is the construction of formal systems that begin with axioms and symbols and combine them using defined rules to produce "programs" (or "theorems" or "sentences"). Our intuition about "math" is rooted in the coincidence that we began doing some of this before we invented computers. We therefore have a body of knowledge about the class of programs that can be explored without hardware.
Wouldn't that be "Programming includes Math" - Mathematics being a subset of Algorithmics.
The vast majority of mathematics has nothing to do with algorithms as understood in programming. To suggest that programming includes math would be to imply that most programmers would be able to "do math". In truth, the opposite is true. Many mathematicians program effectively, I know of no graduate programmer who has contributed to mathematics except in work that clearly lies in the intersection of the two subjects.
There are many skills in common, and I don't doubt that many of the people who do program might have been mathematicians had their career paths and interests been otherwise, but programming is not math, and math is not programming.
Yes, analogies can be drawn, and perhaps each discipline can learn from the other, but to equate the two is like saying that pole vaulting *is* discus throwing. Each requires common physical abilities, but each also requires methods, techniques, training and skills that the other does not.
The evidence suggests that programming skills and abilities are a non-trivial (in other words strictly included) subset of mathematical skills and abilities. In other words, math is harder.
(I don't see how programmers not being subject experts in the wider areas of the field of math changes the underlying question. Programming may indeed be a sub-set of math, but that still makes it math. We are asking about the nature of software, not necessarily the nature of programmers. Perhaps "is programming math" and "is software math" are two different questions.)
But maybe the reason the industry is in such a bad state is because we have bad programmers who aren't even aware that "programming is math". A way to prove that some programming is not math however: a GUI button can be many different widths. There is no mathematically correct button width for the OK or CANCEL button. This is an art, not math. It is design skills, art, and engineering. You could not offer a proof of correctness for GUI design because it is impossible to prove whether the button width should be 50 width units or 45 width units. However, other parts of programming are very mathematical indeed.
Even math may be used for "art" etc. For example, we went to the moon under Apollo largely for political reasons (robots would've been cheaper even then). Yet we used math to get there. It's a matter of stating what you want, and then using math to find the best way to achieve the stated goal. With clearly defined goals and clearly defined models, math can help find the best routes to achieve those goals. As far as which goals to pick; that's often art, sociology, and politics.
Well the page title could be ProgrammingIsMathArtAndEngineering?
See Also: ProgrammingIsMathDiscussion, MathIsModeling