Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

 

Computing Milieux

Logic, Language, Computation, Mathematics and Software

When Worlds Collide

When Is Programming Mathematics, and Vice Versa?  [last updated 2004-05-05-17:54 -0700]  I thing about the connection of software, computing, and mathematical logic a great deal.  I think about language less often, other than to recognize the traps we make for ourselves in being careless with language.

Lately, I have been wondering about the apparent disconnects between the worlds of mathematics, computer science, and software-development practice (including software engineering).  I have come to think that the inhabitants of these communities are speaking different languages in which the words are all spelled the same.

Along with that, each community accepts serious and different over-generalizations about the connections among their disciplines.  Another factor may be people in one discipline interpreting what they hear from others as being in terms they already know.  The difference is not recognized.  Maybe not even the possibility of a discrepancy is recognized.  (I over-generalize.)

For example, there are computerists that assume that computation accounts for all of mathematics (and maybe physics too), and that non-computational mathematical theories are simply mistaken (something that should make mathematicians wary about borrowing concepts from such exotic shores).  Others conclude that algorithms and programs are the same.  Continuing in this vein, I see the Church-Turing thesis over-extended and then argued with (or taken as settled).

I think there are important and valuable connections among these disciplines.  I think we have not mastered them, maybe not even recognized them.

Some of the current articles of belief don't sit still under close scrutiny.  I am intrigued by that.  Unfortunately for me, it is one of those things that I think is right in front of our noses and should be obvious.  And it isn't.

Sunday I began to doubt myself and wonder whether I will ever have anything to offer in this area that is of any value whatsoever.  This arose in conjunction with a claim, citing Sir Tony Hoare, to the effect that successful programming requires meticulous application of mathematical principles.  We got to this point because I expressed my concern that object-oriented programming techniques were being misunderstood as a metaphor for mathematical structures.

I say it is a serious matter to confuse objects in object-oriented computer technology and mathematical objects of almost any kind. I am alarmed when I then see "class" as used in programming languages identified with "class" as in mathematical logic, model theory, and other mathematical conceptions.  I know computerists who espouse that conceit (and also claim that their objects model the real world), but I was startled to see it lobbed in from the mathematical sidelines.  I think these missteps are at least category mistakes, and I don't find them harmless.  This collapsing of distinct concepts together corrupts language, trivializes mathematics, and obscures the power of computation yet to be realized.  That's my thesis.

Listening to the masters. It is difficult to speak into a discipline from the outside in wanting to make a distinction that is not speakable (or easily heard) in the parochial language of choice.  Here are three statements that I think capture what I want to point at.  I invite people to avoid disagreeing with them and simply consider how they might be providing a valuable perspective (and not any absolute truth):

"I don't even know how to formulate the concept that a METAFONT program draws a beautiful letter A, so I couldn't possibly prove the correctness of such a program. But still, somehow, the theory that I've learned while doing computer science gives me more confidence in the programs that I have written." Donald E. Knuth, Things a Computer Scientist Rarely Talks About, pp.17-18.

"Beware of bugs in the above code; I have only proved it correct, not tried it." Donald E. Knuth (in a memo to Peter van Emde Boas)

"As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality." Albert Einstein, Geometry and Experience (1922).

What Is There to Notice? Maybe it helps to look at programming as actually done.  There is more than enough to go around.  Start with Linux source code and see how much mathematics is found.  If there is disappointment about the absence of Object Oriented Programming, look at the Java source code for the Eclipse project.  The specifications for Java and for its standard class libraries are available on-line.  There is some mathematics there.  Go look at the lists of open and closed bugs and see how much of it is mathematical activity.  Look at the information on what is called reflection in object-oriented systems.  Try that as a foundational mathematical structure.

All right, I'm being strident.  I think software development is far more like engineering than like mathematics, even though many programmers (not knowing much about engineering) fight that idea.  I won't dispute that makes software engineering a discipline in which mathematics is applied.  In my experience, software development is more like deriving a cooking recipe than mathematical activity (unless some respected mathematician asserts that mathematics is more like that too).  Also, I am not picking on Victor.  We've swapped notes and I share his interest in computational mathematics.  I would like him and others to be more critical in what it is they say they are doing, that is all.  That is a lesson for me too.

Another way of looking at programming is that it is like enacting procedures that involve only arithmetic (although the arithmetic may be one over interesting kinds of data, such as coded text), copying (rewriting), and comparison.  I don't know about you, but when I did arithmetic "by hand" to reconcile a bank statement and my check book, I didn't think much about the mathematics of it. I have sat down and confirmed the mathematics by which the reconciliation procedures actually work, but I doubt many bank customers have done that.  I did it because I could and I wanted that understanding of what I was doing.  When I used a calculator, and then software, I thought even less about it. Mathematics hasn't helped me one bit in resolving a failed reconciliation, except in one way: I believed in the mathematics enough to know that there was a mistake somewhere, and I believed in my experience enough to look for my mistake first. I did find a bank error once: In the statement, not in the balance. (Through some misadventure, the starting balance for the current month was different than the ending balance on the previous month's statement, and the difference was the amount of a valid transaction that never did show up on a statement. That was over 30 years ago.)

I suppose one could claim that I am tacitly doing mathematics even though I don't have my attention on it.  For me that is like arguing that a chef is tacitly doing kitchen chemistry.  It might be true, but it doesn't seem very apt as a characterization of good cooking.

If one is willing to consider that there really is very little mathematical practice in writing programs, and that is increasingly the case, would it be a good thing to force more mathematics onto programming?  I think maybe we just want to drive the car, not know why it works.  So fussing over the mathematical aspects of software may be largely beside the point and, where valuable, may require the attention of specialists, just as assembly language programming now does.

Well, what is there to gain from this perspective?  You tell me.
posted by Dennis at 5/4/2004 01:27:57 PM