Programming Is Mathematical Engineering

Thought provoked by discussion on StringComputation:

A program is essentially a mathematical artifact; something that describes symbol manipulations. A programmer designs that artifact, much like an ElectricalEngineer? designs an electrical artifact. -- DougKing

You're confusing logic and math, two totally different subject domains. -- IvanTkatchev

Tis not. Programming is much more than that. When mathematics can model any part of reality, including browsing the newspaper and deciding to walk the dog, it will be complete enough to model all activities in software. Personally, I hope it never gets there. I would hate to have to write everything in FortranLanguage. -- PeterLynch

Not just arithmetic -- mathematics. Mathematics includes logic, set theory, group theory, etc. Basically any manipulation of symbols according to rules. By this definition, a Turing machine is a mathematical artifact, and so is any program implementable by a Turing machine.

I didn't intend to imply that programming was describable by mathematics, any more than electrical engineering is describable by electronics. Programs can be modeled by mathematics, but not programming or programmers; rather programmers design mathematical artifacts with a method called programming, much like electrical engineers design electrical artifacts with a method called engineering.

Position otherwise known as ProgrammingIsMath.

A just no. As I understood the point, programming is about applying math or manipulating mathematical concepts. In symbols, not P == M, but P == F(M) ;-)

I don't believe that ProgrammingIsMath, or that programming can be modeled by math, or that programming is only about math. My fundamental belief here is that a program is a mathematical artifact. Programming is mainly about designing that artifact. Combine that with the typical "Foo Engineering is designing Foo artifacts", and you end up with programming is mathematical engineering.

I, as a PhD in mathematics and as a contract programmer, don't understand what you mean by "a program is a mathematical artifact." I think it isn't a mathematical artifact. I think a program is a program, and while mathematics can be used to reason about a program is effectively never is. Juggling patterns can be reasoned about mathematically, and in my experience that happens more often. Can you explain clearly what you mean by a mathematical artifact, and provide some examples?

What I mean by a mathematical artifact is something (probably abstract) whose basic representation is symbolic, such that it can be manipulated and reasoned about using a set of rules. Given the rules and the mathematical representation of the artifact, you can reason about the artifact and its relationship to other artifacts.

Some examples of mathematical artifacts are geometrical: a point, or a 3-dimensional sphere in ordinary 3-dimensional Euclidean geometry. The fact that it's 3-D Euclidean provides us some rules, including how to calculate the distance between points. A point can be specified by 3 Cartesian coordinates. A given sphere can be represented mathematically by specifying its center point and its radius. Consider these rules: a point is inside a sphere if its distance from the center point is less than the radius of the circle; a point is on the sphere if its distance from the center point is equal to the radius of the circle; a point is outside the circle if its distance from the center point is greater than the radius of the circle. Given a particular sphere, we can tell its volume, surface area, etc. Given a point, you can tell whether it is inside, on, or outside a given sphere.

Now, consider a program: it can be represented as an ordered set of binary values (e.g. bits on a disk, or in RAM). A program is executed by a computer, which provides the rules for manipulating and reasoning about the program. (In the case of interpreters, the interpreter is just another set of rules strapped on top of the computer, which can continue ad infinitum).

This is why I see a program as a mathematical artifact. I think the reason nobody actually reasons about them mathematically is that "it's too hard". 

 for (int i=0; i<array.length-1; i++)
     for (int j=i+1;j<array.length; j++)
         if (array[i] > array[j]) {
            temp=array[i];
            array[i]= array[j];
            array[j]=temp;
         }
See ProofAnnotationsForBubbleSort

I hope this doesn't come across too strongly, but I think you don't really understand what research and working mathematicians actually do - your beliefs are born of ignorance. The reasoning about program "correctness" in programming is to mathematics as whittling is to ship-building. The skills have a vague similarity, but the tools, methods, products, effects and purposes are all different. The analogy you draw between programming and mathematics is as useful as saying that playing the piano is doing mathematics. There are similarities to be drawn at some level, but it's entirely pointless.

What is this drive for programmers to claim that programming is math, or the act of programming is just like "doing math"? Why not recognize that it is, in fact, totally different, and that mathematics applies in some aspects and in some ways because mathematics applies to everything in some aspects and some ways?

I'm intrigued that you claim what I said is nonsense, but if you can't find sense in it I'll let it pass. I'm also not trying to argue from authority, I'm just trying to give you some context for your replies.

Consider just how many programmers are like Gregory Chaitin? Indeed, how many mathematicians are like GregoryChaitin? Or like Dijkstra? I am familiar with work by both of them. In Dijkstra's case I'm involved in the transcription of his letters into soft form. As I said, programs can be reasoned about mathematically, but most programmers, the overwhelming majority of programmers, don't. The kind of reasoning the overwhelming majority of programmers are doing when they produce code is not mathematical reasoning, unless the term is so watered down as to be meaningless.

I won't convince you, this discussion will go nowhere. Let me ask instead - of what value is it to claim that programs are mathematical objects, and that programming is mathematical engineering? How will your and others behaviour change as a result of "knowing" that?

Maybe I'm wrong. Maybe the complete inability of many, perhaps most, programmers to follow any halfway complex mathematical proof has blinded me to some essential truth that you are trying to express. Maybe you can enlighten me. Maybe programs are mathematical objects, and maybe programmers do reason about them. Maybe these sorts of claims aren't just discipline envy, and maybe recognizing this will lead to great leaps in the production of programs. I don't see how claiming, truthfully or otherwise, that programs are mathematical objects will help. Maybe I suffer a lack of vision, and maybe this is the greatest advance in computing since Turing.

I ask again, how will your and others behaviour change as a result of "knowing" that programs are mathematical objects?

I am one of those programmers for whom even simple mathematical proofs are incomprehensible, yet I've been successfully developing software for over two decades and have no difficulty understanding "difficult" programming concepts, programming paradigms, algebras (such as the relational algebra), abstractions and abstract concepts, and so forth. As best I can describe it, software is like machinery. I visualize software (to the extent that "visualize" is correct, and it isn't, really) the same way that I visualise mechanisms built from rods, levers, gears, or pistons, and yet it is entirely unlike these. A programming loop, for example, is very different from a gear or piston but a loop is a piece of machinery in the same mental category as a gear or piston. I use the same "brain muscles" to read source code that I use to figure out how a clock or typewriter works. I use the same brain muscles to write programs that I would use to invent a new can opener, mousetrap, or car engine. I'm sure the reasoning that goes into this imaginative process could be described by mathematics, but the thinking that goes into it is not mathematical reasoning. It is something else.

Mathematics, to the extent that I understand it at all, is something entirely different and doesn't seem to occur in the same part of my brain. Over the years, I've queried a number of colleagues about this. They generally fall into two groups: Those like myself who view programming as something not unlike designing a machine, and those who view programming as a form of mathematical reasoning. The style of programs created by these two groups is often very different in a rather intangible way, but I wouldn't say that the "mathematical" style is any better or worse than the "mechanical" style. Nor is the "mechanical" style necessarily sloppy, as was implied somewhere above.

It's perhaps worth noting that a mechanical programming mentality does not preclude using tools and concepts generally considered to be mathematical in nature, such as APL, functional programming, and the like. Years ago, I used a mainframe APL implementation as my favourite calculator. For better or worse, I simply view such mathematical constructs as more machinery for mangling strings and twiddling bits.

To those who program in a mathematical style, maybe it is helpful to regard programs as mathematical objects. For those who program in a mechanical style, it is no more pragmatically useful to regard programs as mathematical objects than to regard neurosurgery as biology, or applied linguistics as anthropology. -- DaveVoorhis

A few responses:

Then the fundamental question left to answer is "a quoi bon" ? And this can be answered trivially, as there are good reasons

So the only contention left is that if some folks can come up with good enough programs, and they don't feel like doing mathematics or they have no formal mathematical training (even if I contend that the ability to come up with programs that meet requirements is an irrefutable proof of mathematical skills), that situation in itself will refute the claim that programming is a mathematical activity. But this in no way undermines the thesis that programming it a mathematical activity. Let's imagine there are no music players (no CDs, no radios, no nothing), so human players are in high demand, there's an economical overriding demand for music played by humans (in some parts of the world, this situation is real). As such most of the people serving this demand are amateur musicians, with no formal musical training. But still this large category can play music quite well. So they don't know the musical notation, they can't tell the measure but they still play their instruments to a quality level that meets the market demand. Is what they are doing still music ? You bet it is.

Such is the case for the mathematical activity called programming. If folks can come up with useful programs while neglecting the proof aspects of it, and relying more on their intuition than on their logical reasoning skills, this only proves that there is a class of mathematical objects that humans can construct acceptably based on their intuition, just like there is a class of music that talented folks can play acceptably without having to go to Julliard. Indeed, programs are not the first class of practically useful mathematical objects that folks had to come up with a heuristic of their own, outside the mainstream mathematics. Before Danzig had solved the linear optimization problem, a great many deal of people (some of them I presumed mathematicians) had to solve practical instances of the problem and came up with solutions that fit the constraints, that were economically acceptable to them. So programs are not the first and probably won't be the last kind of mathematical construct that are built using let's say "less than mathematically tight methods", because of economic necessity.

Does mathematics need side-effects to be useful?

That's an essay question, and the answer is left as an exercise for the reader.

JulyZeroFive

CategoryDiscussion

EditText of this page (last edited July 27, 2005) or FindPage with title or text search