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.
- Agreed, but that's the same position as that defended in ProgrammingIsMath (or at least the intention behind it. What is saying is that programming is a particular sub-domain of Mathematics not that Programming == Mathematics (if you agree that applied math/mathematical engineering is part of Mathematics), i.e. mathematical engineer is one kind of mathematician.
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".
- Actually programmers do reason about their program "mathematically", meaning the process that goes into their heads while writing a program is a form of "mathematical reasoning", albeit informal and sometimes maybe undisciplined and sloppy, because formal reasoning (i.e. writing formal proofs that can be verified by a proof checker) is still too damned hard, and even the quasi-totality of classical mathematicians don't do it. The sloppiness of programmers is in essence no different than the informality with which a mathematician may publish a proof that jumps over minutiae details of some steps, or says "the case for X is symmetrical". "we see that ..." and other kinds of prose that gives the indication of the proof rather than the actual proof. But take even the simplest implementation of sort, the way a programmer comes up with it and convinces himself of its correctness is a form of mathematical reasoning, and it is not different in essence from the process of coming up with the proof for a theorem. Ex:
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?
- Complete non-sense added to argument from authority. Programming languages are formal mathematical objects. Programs are formal mathematical objects. The analogy you draw with playing piano is useless. Research mathematicians are not the only kind of mathematicians in the world, other mathematicians (graduates of Mathematics) are at work solving concrete mathematical problems for practical purposes (otherwise known as applied math), and although such an activity is quite different from what research mathematicians do, they are no less mathematicians than the other category. "Why not recognize that it is in fact totally different?" -- because handwaving was never recognized as argument.
- So if you contend that programs are not mathematical objects, what the hell do you contend they are? States of the magnetic material on a hard-drive? Go read some EwDijkstra before you dare to accuse others of ignorance. And speaking how "research mathematicians" do something very different, you may want to read up on one particular research mathematician called GregoryChaitin.
- Besides which, this page doesn't claim that programming is math; it claims that programming is engineering, and that the subject of the engineering is programs, which are essentially mathematical constructs.
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?
- The value we derive from claiming that programs are mathematical objects is to establish a matter of fact. If you try to establish what are programs by the "genus proximus" method it is inescapable that in the hierarchy of concepts they are firmly rooted under the umbrella of Mathematics.
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.
- What is the simplest mathematical proof that is incomprehensible to you? At what stage do you fail to follow it?
- Generally, my brain throws an exception immediately after the text says, "here is a trivial proof for the above..."
- Also, is there something missing from the sentence beginning "Essentially, I flex"? You lost me at the "to when understanding" bit.
- Yes. I garbled the sentence, and have now fixed it. DeleteWhenCooked
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:
- In absence of monitored experiments (MRI and all that jazz) all the claims about parts of the brain and brain muscles are handwaving, and at best irrelevant.
- To claim that functional programming or relational algebra is more mathematical in nature than say programming in Java, or PERL or even assembly is akin to saying that differential equations are more mathematical in nature than geometry. The basic output of programmer's activity, regardless of paradigm, is still a mathematical object, albeit in different formalisms. If you have 2 mathematicians side by side, one solving a system of differential equations, and the other solving a geometry problem it would be quite ridiculous to claim that one activity is more "mathematical" than the other.
Then the fundamental question left to answer is "a quoi bon" ? And this can be answered trivially, as there are good reasons
- Because it's true. Claiming something that is a matter of fact, shouldn't need any more justification
- Marketing. That's how the agenda of EwDijkstra, R. Floyd and all the other pioneers can be pushed forward and be recognized by the large unwashed masses. As this marketing scheme is based on pure unadulterated truth, it is quite legitimate. And it's not some academics down in a forgotten corner that want to push more mathematical awareness into programming, on the contrary this agenda can be found in mainstream industry like at Microsoft.
- Provides the only true insight for the eternal design problem. How to best design the interface for service/component/object/database schema X ? The answer is the same as in approaching mathematical problems. The quality to maximize in a design is EconomyOfProof?. How easy it is, given the contract between a client context and a provider context and the expected usage of the interface, to make an argument that the desired properties are realized. All the other design criteria (minimizing coupling, OoDesignPrinciples, data modeling principles) are either derived from this, subordinated to it, or sometimes are an irrelevant distraction.
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