Last week's licensing discussions sprouted an interesting, if off topic, thread on a number of computer language related issues. One of the issues raised strikes me as fairly fundamental: is software a form of applied mathematics?
Here's how occasional contributor b3timmons stated one side of this argument in response to the quoted bit from an earlier comment by Anton Philidor:
Software is a form of applied math"You'd have a difficult time persuading someone looking at computer code that he's seeing mathematics at work. No calculations (say), no mathematical terms, created by someone who is poor at mathematics (say), and used for a purpose like recording a set of recipes that has no obvious mathematical implications."
On the contrary, it's easy to show anyone that code is math, since code is just a list of instructions that take a machine from an initial state to another defined state. Such a list is otherwise known as an algorithm, which originated with mathematics and notions of abstract machines.
In the best tradition of the consulting profession I'd like to say that both sides are exactly right here because software both is, and is not, a representation of applied mathematics. More precisely, my belief is that science derived software reflects its mathematical heritage, but data processing software is purely heuristic and generally has no theoretical foundations.
Konrad Zuse's 1938 Program Calculus was probably the first true programming language and the intellectual ancestor to Iverson's APL. Like APL, it was designed to use the computer for the advance of mathematics and incorporated the key ideas of algorithm, provability, and problem framing.
As part of making his case Iverson and one of his colleagues, D.L. Orth, wrote several teaching textbooks for mathematics in APL - and these stand today as the premier examples of the integration of programming language development and mathematics.
Eventually, the people who preferred traditional notations won the battle with the result that Maple and Mathematica now dominate the market for the direct exploitation of computing in mathematics - but these are radically different in conceptualisation from APL. APL implemented mathematics as a computer language; Maple and Mathematica interpret and manipulate traditional mathematical symbolic constructs.
Data processing, in contrast, had been evolving the card deck for forty years before Zuse built his computer and had, by the mid nineteen twenties, reached the point of being able to assemble decks and machines into processes - generating, for example, general ledger reports by processing batches of general journal entry cards according to sequentially applied sets of rules on sequential machines.
In those days job control was exerted through the work process with each step demarcked from the steps before and after it, and each machine carefully cleared and reset before each new batch - with only the right sequence of the right batchs done in the right order on the right machines producing the desired output.
Today it's all done on the same machine under JCL, instruction cards have been turned into compiled COBOL, data cards have become database records, and the output usually isn't printed anymore - but the overall process is exactly what it was then. Look at COBOL today, for example, and you still have the head movement and clearing instructions for IBM's 1921 Hollerith Type III electro-mechanical Tabulator.
The data processing stuff, no matter how many layers of adaption and evolution separate it from the original, continues to follow purely heuristic processes - right down to the audit controls that evolved to work with these machines during the nineteen twenties. As a result it can be described mathematically, but is itself no more mathematical than a kick in the head - which, by the way, can also be accurately described mathematically.
So, bottom line: is software mathematical? Yes on the science based side, No on the data processing side.