Programming Is Math Discussion

The old ramblings and ThreadMode from ProgrammingIsMath

If I am not mistaken, I think that all contributers to this page would agree that more mathematical approaches to programming could be a good thing. We seem to be talking at cross purposes sometimes.

That should be true. So, for example we should (as opposed to shouldn't) be asking if OO has a sound mathematical foundation (it does, that's trivial). Or more precisely , we should be asking why OO systems don't have mathematical foundations that are more complete and closer to what's needed - see BadEngineeringPropertiesOfOoLanguages.

Likewise, we should not ask, seemingly surprised, What mathematical foundation? implying something like What UFO? Why do we need UFOs at all, we're doing just fine without UFOs?

[That question's purpose was to elicit clarification of what lay behind the original point.]

The page IsProgrammingMath refers to the practice of programming, about which this is certainly debatable. The fundamentals of computation, which is the subject matter of C.S., are clearly mathematical. However, much of programming practice today has little to do with these fundamentals. More's the pity, some would say.

IsProgrammingMath is not a debate as long as it goes on with rants rather than facts. The facts are simple: math is the very essence of how computers and programs work.

The whole point of that page is that you don't need to know advanced computer science (or rather any CS at all) to do some decent programs. That's true as long as you don't forget the some quantifier. But going from there to advance such statements as "we shouldn't be asking whether or not OO has a sound mathematical foundation" (why? does it hurt or something?), and let's forget mathematics because "Ultimately, truth has to come from empirical observation ...", is at best a logical fallacy.

It suffices to say that you don't need to use advanced math to do math. A 9 year old kid who solves "ax+b=c" is still doing math, even if very basic math. Likewise with programming, as long as you use VisualBasic to put some controls on the screen and connect them to the fields in the database, with a few mouse clicks and 0 lines of code, you're still putting together a fairly complex mathematical construct, even if the difficulty left for you to solve is roughly the same as that of "ax+b=c". Sorry, but the theory of computation and advanced algorithms is not all there is to "the mathematics of computers". That's a RedHerring.

Then, another fallacy comes from arguing that people without much training in math can produce decent programs. I also can say that I know many fine gypsies who have no clue of musical theory, but they can play folk songs perfectly. So, should we draw the conclusion that music doesn't need musical theory, and it would be better if musicians would study geography rather than wasting their time with musical theory??

: This may be the wrong analogy for proving your point. There are a number of brilliant musicians who have little or no training in music theory. There are also a number of brilliant musicians who will tell you that a little music theory is useful, but too much is poison. Yeah, music theory is interesting, but most people don't like atonal geniuses like ArnoldSchoenberg?, so what does that say?

Well, some areas of mathematics are as incomprehensible for me as Schoenberg's music:) But the point was that those gypsies are not going to play the 9th no matter how talented they might be, and they might get in serious trouble even with EineKleineNachtmusik?. Going back to their music, which happens to be both artful and enjoyable, some basic things that musicians theorized will apply also to gypsy music; it's music after all. Even if they use more intuition than knowledge, they're still doing music.

Likewise, any programmer will still end up creating special kinds of mathematical objects, that we may call programs, database schemas, SQL queries, objects, components and what have you. Yes, he may end up creating those things purely using his intuition and not mathematical reasoning. So we can say he developed a special intuition about the mathematics involved in programming, and intuition is a prized quality even for mathematicians. But there should be more than intuition in there to get quality stuff out.

It's also clear to me that promoting the idea that we don't necessarily need mathematics to do programming is simply promoting ignorance. We might need other ingredients as well, but math is what keeps everything together. Ignorance has led many apparently simple projects to failures. It's not worth debating here, it has been documented in all too many books and most of us probably have seen it in practice.

Who has argued that programmers can be totally ignorant about math? I say programmers should learn everything that is helpful to their job. That includes some math, without a doubt. In my experience, it also includes a little writing, and a little human psychology. -- FrancisHwang

Would you be so kind to reread the introduction to IsProgrammingMath? It is simply a plea for ignorance, unless I have a terribly misunderstanding of English. A reasonable hypothesis, from where I sit (that you have misunderstood).

Reread. I don't see what in that introduction leads you to believe it's a plea for ignorance. Nowhere have I said that programmers don't need math. Programmers should know some math, just as geologists, economists, and political scientists should know math at all. Can you quote specifically what part of my IsProgrammingMath introduction makes you feel that it's a plea for ignorance? I feel like we're having a big disconnect here. -- francis

: The idea that programming needs math is fine, but is not what this page purports to be talking about. Physics needs math. Physics is not math.

I definitely agree that there is more to programming than pure math or pure computer science, and we can also say that there is more than pure math to math. Math itself hasn't been created just as an abstract exercise of our brains. And it should be clear that the page's title is to be interpreted as "programming is in essence about math" and not programming=math. What can you do when somebody puts the overly simplifying question IsProgrammingMath:)

: I still don't understand how IsProgrammingMath is overly simplifying, while ProgrammingIsMath is edifying and to-the-point. Isn't one simply the response to the other's question? -- francis.

Programming needs math, and programming bottom line is the creation of mathematical objects that "program" physical devices that will solve practical problems. It's not philosophy that gets executed in the CPU, it's mathematics. And if you put n layers of abstractions above the CPU, the n-th layer will still have a form of mathematics in it, and the interface to the n-1 layer is still math. What more needs to be said?

There are many more examples of misguided arguments on IsProgrammingMath, but I'd rather stop here.

If it has a UI, it's not a mathematical artifact. Most of the books you are thinking of probably don't deal much with that side of things.

Sure, the color of the text, the shape of the buttons, the layout and so on, they're not math. However, would you care to say how it works?

Sure. There's your guy, in the middle of the screen. When you hit the arrows, he moves one unit in the appropriate direction, and when you hit the spacebar, he freezes and holds out his sword for a set length of time. Those other guys are enemies, and so far, they're just moving directly to randomly chosen positions on the board. If they touch your sword, they lose a hitpoint, and if you touch them, you lose a hitpoint. Anyone who has zero hitpoints is removed from the game.

Sure, this little game makes use of some mathematical concepts. And when you code, you're representing the whole thing as a recursive function with free parameters to be determined by hardware. But is this really the best way, or even a natural way, to think about it?

Well, you already did your job of modeling the action in mathematical concepts. You can think about it any way you want, you'll still be creating those mathematical objects that will be interpreted by the hardware. And if you end up with those functions not having certain mathematical properties, the whole thing is going to crash on you. The same is true about OO frameworks, database designs and any other artifact of programming in the larger sense.

If you invent some kind of mechanism that will allow you to come up with those mathematical objects in whatever "non-mathematical" way, I'll ask you if you didn't discover a new area in math. But as long as the most basic constructs like boolean expressions, variable declarations assignments, loops, are in themselves mathematical constructs, I'm afraid we have no point to debate here.

Ok, I understand where this is going. Programming is about dealing with objects that hopefully have set properties, and the moment something has set properties, it can be described in terms of mathematics. This doesn't make programming math, but the above says that nobody really wanted to say so, but rather were trying to argue that programming is about math. In that case it's true, but vapidly so.

And who are the BillGates and RichardStallman of math, anyway?

I would say programmers are certainly practising math on a daily basis. Let me motivate this statement. All programs require at least an intuitive understanding by the programmer that the code will actually do what it is supposed to do. The programmer may not realize this, but on some level the information contained in this intuitive understanding, if correct, must be loosely equivalent to a mathematical correctness proof. Even if the programmer does not know how to express this information in mathematical symbols, he/she is still constructing some equivalent internal representation of it. As an easy exercise, review your understanding of the Quicksort algorithm. The act of understanding the Quicksort algorithm is (even if unconsciously) pretty much equivalent to constructing the elements of a simple proof by induction on the natural numbers.

For understanding Quicksort, yes, that's mathematical stuff. But most programming work is nothing like dealing with sorting algorithms.

In addition, almost all programs require classification of types of objects, reasoning about types and functions/transformations involving types. First, the act of classification (understanding and defining the relevant types/classes) is quite sophisticated in most modern software. This kind of classification activity forms a major part of the work of a modern mathematician. Furthermore, to do anything useful, the programmer must have some representation of the properties of each type present in his mind (loosely equivalent to a set of axioms) and he or she must construct fairly sophisticated chains of reasoning to obtain derived properties of types and transformations pretty much all the time. Again, he/she may not be writing down these chains of reasoning, but they are there in some form in the programmer's head and are pretty much isomorphic to mathematical proofs.

So all reasoning regarding types and classification is necessarily mathematical? Does that make biologists mathematicians, when they're figuring out what genus a species belongs to?

As a harder exercise (tongue in cheek), take a random program in Haskell involving monads and figure out how it does what it is supposed to do. Tell me if the resulting chain of reasoning is not mathematics.

I am perilously close to merging this page in with IsProgrammingMath. Please see my note there. -- FrancisHwang

Just don't do it. Stay still for a while, and you can refactor all you want later. Ok?

Could you give me a more specific reason as to why I should wait? To my mind, these two pages are already so sprawling that they're practically worthless. -- francis

I guess it has apparently cooled down, that was the reason.

I would say go for the refactoring.

To the statement - "I am perilously close to merging this page in with IsProgrammingMath. Please see my note there. -- FrancisHwang"

Removed my comments here (and those it generated) in favor of the later refactoring by a mathematician, pageRefactorer, programmer, anarchist, or philosopher, (whichever prevails or persists) regards, -- OnlyaStudent.

Francis, you got it all wrong. This is not a debate and it is not debatable. ProgrammingIsMath is a matter of fact for a large number of software engineers and computer scientists, by informed and assumed choice. Other people tend to drift away towards architecture, poetry, phylosophy and other liberal arts. ProgrammingIsMath is also the legacy of such geniuses as RobertFloyd? , EwDijkstra and many more. I'm afraid it's not up to you or anyone else around here to debate that. And certainly, debating it at the level of amateurism that we all enjoy on wiki, is most ironic.

It looks like you kind of chose that for you programming is not math. I can understand your choice and what can I say, I'm afraid it is your loss and you might want to reconsider, however I wish you good luck with it. I'll try to refactor this page later to reflect this. --CostinCozianu

I offer the suggestion: HowIsProgrammingMath?, and ProgrammingIsMath (or something in the same vein). Basically, one page to describe, to those who may be unsure or simply disagree, why programming can be considered to be math (or why the question is non trivial, potential of this view, etc), and how to gain benefit from that point of view (program derivation, analysis, more concrete advice on how this is useful, day to day) --WilliamUnderwood

Maybe IsProgrammingMath and ApplyingMathInProgramming?? -- francis

Definition of Math

This gets into the issue of "what is math". I tentatively define math as "language with well-defined rules". But, I don't think this excludes programming code though (except maybe for VB :-) There needs to be some tranformational component to it. You generally don't "transform" programs using math or symbolic reasoning rule engines. It is usually hand-done, although compilers sometimes apply rules to code to simplify the structure. Some languages are more "tranformational" than others. Thus, maybe "mathness" is continuous instead of Boolean. Boolean math is very transformational, for example, because you can apply the rules of BooleanAlgebra to simplify or transform Boolean expressions without changing their meaning. I have yet to see something massively transformational done on say a COBOL program.

All compilers ""transform" programs using math". Compilers are "symbolic reasoning rule engines".

{Not into the same language}

You can, if you want to. All compilers could transform source code into TuringMachine code. They don't for performance reasons, but that's one of the consequences of TuringCompleteness?. All of them can emulate each other. Anyway, I don't see why it matters if they tranform themselves into the same language or different languages. Can you explain?

Here is my latest working definition of "math": Usage of a symbolic language built with a fixed set of symbol primitives and fixed set of precise base rules based on the language which facilitate the manipulation of the language within the framework of these rules. (Note that the derivation of new rules is not excluded; the new rules are simply not "base" rules.)

All software conforms to this definition of math.

To some degree, yes. But like I said above, it is not all-or-nothing.

Sure it is. All programming consists of ordering logic rules for a TuringMachine. Math is expressed by logic and verified by logic. Logic can be expressed and verified mathematically, as Goedel showed. His GoedelNumbers? have evolved into addresses. Various sets of logical syntaxes have been written or wired into instruction sets. It is all math. Everything that a CPU or virtual machine does is math. It is all, not nothing, not in between.

"Doable" and "practical" are not necessarily related. May I suggest CriteriaForGoodMathOrCompactNotation. We have "good math" and "sloppy math".

Programming is a set of abstractions that help us set logical gates on silicon. Programming is logic. Logic is math. Programming is math. There is nothing sloppy about it. It is "doable" and "practical".

If I am interpreting that right, then we should all just write our software in machine code or bytecode, and forget about this "high level language" stuff.

Then you aren't interpreting that correctly. There's no good reason not to use abstractions in math.

Well, there is good abstraction and bad abstraction, and there is good math (or notation) and bad math.

Are you saying programming is bad math? Or that programming languages employ bad abstractions?

Programming is not fundamentally math unless life and thinking are fundamentally math.

Computers are clever arrangements of switches. The physics/electronics of computers is quite something else. To confuse how the machine is built with how the machine is used is a mistake.

Dijkstra pointed out that a fundamental asset to a programmer is a command of his native language. The expression of a sequence of logical states as math can be accomplished, but that doesn't mean that either thinking or programming is math, any more than chess is math.

Remember, ProgrammingIsInTheMind. Its expressions are a function of language and, just as it is possible to utter nonsense in spoken language, so it is equally possible to utter nonsense in programming.

-- GarryHamilton