Is Programming Math
Is Programming MathSome people think programming should be viewed as fundamentally based on math. Others think that programmers simply use math in their work, like physicists, mechanical engineers, and ecologists, but that it doesn't follow that programming is math.
Programming was historically built on a mathematical foundation, but is that the case anymore?
What mathematical foundation? Some early use of computers may have been in relation to mathematical problems, but that's not at all the same thing as programming having a mathematical foundation.
Turing dreamed up his self modifying typewriter to solve a math problem, Hilbert's EntscheidungsProblem. All logical computation is math. Programming may not look like it anymore, but everything we do eventually tells a machine to perform mathematical functions in a specific order.
They are not all mathematical functions. Printing "hello" on a screen or drawing GUI buttons isn't all mathematical. It's like claiming that when you paint a house you are just telling the paint can and brush mathematical equations. Some of it is artistic, some of it is engineering. Some things may be calculated like how much paint to use, or how many buttons or Hello greetings to use, but it certainly is not all math.
No. Programming is logic, and logic isn't math. (Rather, math is the language of science that is expressed using logic.) :) -- IvanTkatchev
Logic isn't maths? Since when? NickKeighley
But since programs are somewhat ethereal in nature, a capacity for understanding symbolic systems and abstractions tends to be useful, even if the techniques, concepts and values of Mathematics are hardly ever used.
There is an obvious difference between programming and math. In math, you cannot say BugFreeDoesntSell about proofs.
I wish that programming was taught like math. In my math courses, you showed all of your work and you were graded primarily on the logic and clarity of your logic in solving the problem. Coming up with the correct result was secondary. In my programming courses, the professors never cared to look at your source code and anything that produced the correct result was acceptable. I think it is time to put this black box hokum behind us and start to teach clarity in code from the start.
Programming most certainly isn't math, but you can make an argument about computer science being a (small) corner of discrete math. There are two camps about this. Still, computer science is not programming. CS may be attempting to form a (yet unrealized) solid foundation for the practice of programming, but that certainly doesn't make them equivalent, any more that physics is mechanical engineering.
Many programmers would benefit from a little more knowledge of elementary mathematics, but that is not the same thing at all. Almost no programmers are mathematicians, but that is hardly surprising, since mathematicians by and large do mathematics. (Various Wikizens are qualified as both mathematicians and programmers. Perhaps commercial programmers and systems programmers are less likely to be mathematicians, while other categories are more likely to be.)
Many programmers have a fairly weak grasp of CS, let alone mathematics. Furthermore, while mathematical techniques exist for many areas in programming, they are often not used. (When was the last time you asked a manager for a confidence interval on a number they come up with, and got one?) This is probably quite variable across the industry.
A huge number of the things that human beings do can be usefully studied mathematically. That does not make them mathematics. Furthermore, the act of using mathematics in what you do does not make you a mathematician. As for programming specifically, there are vast parts of the practice of programming that have little or nothing to do with mathematics, and can't be solved by its application.
Devising a program for a complex task often starts with breaking the task into simpler ones which, when taken together, are equivalent to the first task. That's an exercise in applied logic, which is a branch of mathematics.
Some programmers do heavy math thinking every day, and I have nothing but the utmost respect for them. I don't think I'm mathematically sharp enough to do anything near that sort of work. But many programmers don't do much math at all. I know how all the different sorting algorithms work, but in the last five years of my professional life I have never had to implement such an algorithm, much less try to come up with one that bests qsort. (Thank Goodness.)
[Hmm. I'll believe that. But long ago, I came across a very small sorting program (written in assembler) which quite a few people (paying customers) were using. It took little trouble to speed it up a bit by reducing indirect addressing. Naturally, the new routine was given a different name, and wasn't given special publicity, but it was freely available and did get used, as far as I know.]
Much of my work these days feels kind of like I'm playing with Tinkertoys: Take this piece and connect it to that piece using that slot. If they can't join up with a third piece without breaking, reconfigure them until everything fits. Continue until you've built your spaceship. That sounds like a facetious way of describing the work, but I know that when things work all this slot-matching results in code that makes my clients' lives easier. I don't need a theorem to prove that. -- francis
[Sometimes, mathematical proofs are put together like that.]
You need to be logical and rigorous, but programming has much more to do with communication than mathematics: not only communicating your ideas to the computer, but to the other programmers who need to read or use your code. In my experience, mathematicians are not always the greatest communicators. -- DavidPeterson
[Communication helps in all subjects, doesn't it?]
You think mathematicians never complete timesheets or never document what they do?
This is quite true. My father is a mathematician (topology) and he would not dream of just diving in and start solving a proof. He would first determine the number of lines of text needed to solve the proof. He would then prepare a list of requirements for the proof, using the proper document template, and get the document signed off by all of the department heads. Next, he would prepare a detailed design for the proof as well as a risk assessment with contingency plans. What to do if the chalk breaks? Only now would he begin to actually write the proof. A disciplined approach is needed, as we are all aware the cost of making a mistake grows exponentially. During this time, he reports weekly to the department head on his proof. Strangely, he is 90% done most of the time. I am so happy that mathematics and computer programming are so much alike.
Ultimately, truth has to come from empirical observation, not a top-down theoretical framework. When you evaluate the usefulness of ObjectOrientedProgramming, we shouldn't ask whether or not OO has a sound mathematical foundation. We should ask whether it works. The two aren't always the same. Programmers aren't all mathematicians, and perhaps they shouldn't have to be.
The reason I asked the question in the first place is this: There are times when people say things like "ObjectOrientation is a mistake because OO programming doesn't have a sound mathematical base." And basically I want to say this: I don't care. I mean, there are plenty of useful things in this world that don't have a sound mathematical base.
I feel like programming as a craft is far too young for us to say "Programming is math", or even "Programming is architecture", or "Programming is writing". Programming is programming. And before we put some big over-arching principle over everything we see, maybe we should be skeptical, open-minded, and above all, empirical. We should take a lot more time to gather information - both in terms of statistics and in terms of personal testimonial - to see what works. Maybe when we understand better what works in programming, we'll have a better sense of what programming is.
-- francis
Empirical, skeptical, open-minded, and all that is good and beautiful. But above all, let us not be forgetful and let us not be ignorant.
A lot of self-appointed (or appointed by the large masses) "gurus", who contributed nothing to the science of programming, recently and not so recently made all kinds of unsupported (and bery often self-interested ) claims along the lines "math does not scale", etc, etc, etc. They don't have even 10% of the understanding of EwDijkstra, nor did they bother to actually read what the man had to say, otherwise they'd have known the old man responded to them in advance. That is not skepticism, empiricism, open-mindedness and all that jazz, it is more like ignorant retrograde attitude.
So here are some facts:
Ok, let's grant ourselves a break here, we don't have efficient mathematical tools, and we have to build upon and integrate a lot of "legacy" that is anything but mathematical and most often a clumsy mess, we have a job to do. But a skeptical attitude works also the other way around: we shouldn't bow down to the medicore substitutes and patchwork that proved nothing so far. What do we *really know* that allows us to say: you know the ProgrammingIsMath approach is not likely to work and not likely to scale and will never catch on and BlahBlahBlah? Or even worse, go one step further and actively denigrate, oppose, detract, and all that jazz. Because if we do that, great chances are (history goes in only one direction) that we might be proven wrong, and that will mean a lot of bad things (TM).
Let's begin with OO and see whether we agree on some facts. Various OO languages, databases, systems have generally sound "mathematical foundations". Let's take Java for example: the Java Language Specification is a mathematical system defining precisely what happens both at compile time and at runtime. Agreed up to here?
I hate to sound contrary, but not quite. I have a problem with this line: "Java Language Specification is a mathematical system defining precisely what happens both at compile time and at runtime." Why is it a mathematical system? Why not simply a rational system?
The mathematics is the essence of it; you can represent it in a mechanical machine, an optical circuit an electronic circuit and so on so forth. Or you can represent it over another mathematical layer - the machine code, which would be a smarter thing to do.
I don't see anything in the JLS that makes it an inherently mathematical system. Yes, lots of the system deal explicitly with math. And yes, all the implementations of the JLS that we know of are done using mathematical machines. But you can also do lots of non-mathematical things with a JLS implementation.
I briefly reviewed JLS, and I have a problem seeing anything at all that's not mathematical: programming language, expressions,types, variables, values, instruction set, virtual machine, etc ... Nor anywhere does it seem that the author is only using mathematical constructs to represent something else, nor it alludes to, either explicitly or implicitly.
To quote: "The book provides complete, accurate, and detailed coverage of the syntax and semantics of the Java programming language. It describes all aspects of the language, including the semantics of all types, statements, and expressions, as well as threads and binary compatibility." What is a programming language, a type, an expression, a thread, and all the others that is not mathematical?
I mean, you can represent the English alphabet using math too - that's what ASCII's for. That doesn't make the alphabet mathematical. (Unless you're asking a Kabbalist, of course. Me, I'm not a Kabbalist.)
Well, some might argue with you that an alphabet is precisely a mathematical construct. But we're not talking semiotics here, we're talking about programs and mathematics.
I really cannot see how anyone can *not* see something like the JLS as a mathematical construct! Doesn't even BNF look vaguely mathy to you? Communication Protocols? FSMs? Is topology maths? NickKeighley
Programming is not math. Programming is to math what building anything is to math. A house is not a mathematical problem. You could use math, along with some empirically derived formulae or tables, to select a beam girth. That does not make building a house math, because even an illiterate craftsman with no knowledge of mere arithmetic can build a fine house using direct measurement and intuition.
Caveat: The declarative and functional programming camps probably have other opinions about this. I roast my marshmallows over the fires of the imperative camp.
If programming is not mathematics, give a list of programming activities that mathematicians do not do when developing mathematical algorithms; also explain how programming is accomplished without mathematics in the form of applied logic.
The person taking your groceries is using arithmetic: are they mathematicians as well? What about a carpenter, applying logical rules of thumb to do his work? Mathematicians do not work anything like programmers, which is immediately evident to anyone in close contact with both groups. In your daily work as a programmer you apply trivial mathematics and logic. So? Hundreds of other professions and trades do as well. This is not in any meaningful way related to what mathematicians do in *their* day to day work.
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 the chain of reasoning contained in this intuitive understanding contains the elements of mathematical proofs regarding properties of the program. 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.
But if the `intuitive' understanding led to a proof of correctness, the program would work a) without flaws and b) across a definable class of inputs. The reality is that this is almost never the case. What programmers usually create is something more like experimental proof of a special case.
Yet programmers are able to write code that works, right? There must be some logical chain of reasoning the programmer follows where creating the algorithm or fixing a bug.
This reasoning is very different from a mathematical proof. Almost nobody is writing something as small, clean, and well-defined as, say, quicksort. The practice of programming doesn't have enough of these solid building blocks, so programmers do other things.
I submit that it is impossible for anyone to understand Quicksort without reasoning about properties and transformations of sequences. How is this reasoning not a mathematical activity?
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.
Programmers do a lot of classification, but not in the same way as mathematicians.
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.
The set of representations that a programmer uses are not even loosely equivalent to a set of axioms (with some exceptions for people and languages that are a tiny percentage of the world's programmers).
Okay, take a List data structure (which most programmers have used). A list is no less a mathematical object than a natural number, a real number, or a group. The properties of lists, i.e., that there are functions to obtain the head and the tail if not empty, that the tail is a list, and that a list can be empty, are certainly no less axioms than are the axioms of natural numbers, real numbers, or groups. The programmer has to keep these properties (axioms) in his head when working with lists. Understanding how to write a simple recursive function to reverse a list requires the programmer to engage in some sort of inductive reasoning based on the properties of lists. I don't think it is possible to arrive at the solution purely empirically. This reasoning involves playing in your mind with the properties of a mathematical object. This is what mathematicians do. This is Mathematics.
Firstly most programming isn't done with things as well defined as lists. Secondly most programmers wouldn't recognise your definition of a list. EveryOneKnows? a list is a line of boxes joined with arrows. And a Line of boxes joined with arrows is GoodEnough to write linked list software. I know because I've debugged their software. NickKeighley
"[A]lmost all programs require classification of types of objects, reasoning about types and functions/transformations involving types" - isn't there an element of linguistics to this, as well?
{Q: If you analyse the same problem with several teams, with different native languages, do you get analyses which have a linguistic bias? Do some teams pick out more nouny-based stuff or more-verby stuff depending on their language?}
Or possibly it's more that this technique is at the same sort of stage in development as maths once was? (The Greeks used to write the problems in words, and now we've developed more formal notation system.)
And just to be controversial, should programming be mathematical? It integrates with business systems and people who aren't clean and precise and logical. At some level, non-mathematicalness is going to show up, surely?
-- KatieLucas
Integrating with business systems and people is the job of eliciting requirements. For example, programming is constructing the programs that conform to whatever requirements (logical or illogical from the external point of view). No matter how the external domain behaves (logically or illogically), the behavior of your programs has to be logical.
When will we get to the point that it doesn't matter how it is done but what' is done? Arguing how programmers are doing their job each day is totally irrelevant. You might look at an optimization problem and use voodoo to come up with a decent result or even with the global optimum. You might feel encouraged to repeat the voodoo next time. However, this doesn't prevent me from saying that you're essentially solving a math problem.
So, if you're writing a program you're essentially solving a functional equation, in the sense of coming up (hopefully) with one of possibly many solutions. You might want to use voodoo to do it but the essence of what you are doing is solving the damn equation. If we don't accept that the problem (creating the program) is essentially a math problem, we'll then find it more than acceptable to use voodoo - it apparently gives some results, and then come up with arguments that we don't need the stinking mathematics after all.
We can come up with the conclusion that given the current state of knowledge, we can't do better than voodoo for the problem at hand (and this kind of statement is potentially provable), but that's not to blind us that the problem is a voodoo problem and not a mathematical problem.
You could turn this question around and ask Is math programming? There's no algorithm for mathematical discovery and mathematicians use intuition or voodoo or whatever you want to call it every single day. If you think of programming as the *process* of coming up with a program which performs a given task and mathematics as the *process* of coming up with a proof for a given theorem, then the cycles of development are very simmilar. You hack at the problem for a bit, then step back and have a look at what you've accomplished. You re-arrange the various pieces, simplify, refactor, realize you've just reinvented somebody else's wheel badly etc... After the first attack on the problem you might observe a previously unnoticed simmilarity between the current problem and some other problem and find yourself able to reuse some well-established techniques, or you might come to the conclusion that the way you have decomposed the problem into its sub-problems is not working out, and throw everthing away to start again with a new approach. Mathematics is not a collection of theorems and programming is not a collection of programs. Obviously programs are not theorems (unless, perhaps, you are a haskell programmer) but the mysterious process by which programs are written and theorems are proved have some striking simmilarities.
Is Computer Science Math?
First, let me define "Computer Science" as the study of programming not programming.
To take this analogy further, I would say that Object Oriented Programming theory is Set theory. Yon can take any class hierarchy and redraw it as a Venn diagram (the one with the overlapping circles) with no loss of information. Base classes are merely overlapping subsets of derived classes.
I will also predict that before they are useful, concepts such as "cohesion" and "coupling" will have to undergo a mathematics-like investigation to become useful to programmers.
Programming seems more like Physics than Maths. In theoretical physics, the intended results (cf. user requirements) are usually known, you then make up a theory (cf. your program), and then do the calculation (cf. run tests) to see if the theory gives the intended results.
EwDijkstra was convinced that programming was math. More specifically, he asserted that writing a program was essentially the same as creating a proof. His view was shared by CarHoare, and also by NiklausWirth I think.
You could say that a program is a proof that some set of requirements can be completed (though some of the code I've seen is more like a counter-example). LambdaCalculus, the theory that underpins FunctionalProgramming, shows that programming is something that can be modeled mathematically, and so the theory that ProgrammingIsMath is not something that can be dismissed outright.
Although programmers don't "create mathematics" in the sense of discovering new theorems, when we program we are doing math in a certain way. We're essentially solving a special kind of equation: what program fulfills the specification? A computer program is essentially a mathematical object - it's not physical, philosophical, or literary. It's mathematical.
Saying that 'a program is a mathematical object' and saying that 'programming is math' are two logically different statements. The first statement does not imply the second. One characteristic of a program is that it can be represented as a mathematical object. This is trivially true. However, this does not in any way make the practice of programming the performance of mathematics. Nor does it even imply that mathematics is a central part of what programmers do; this is a separate, albeit related, issue from what characterizes programs.
But other people who use mathematics don't have as their primary task the creation of mathematical objects (programs). Even if programmers aren't applying mathematics, they're still solving a mathematical problem. Sometimes they use non-mathematical tools, like intuition and heuristics, and this is possible to a great extent because much of the mathematical complexity has already been solved by the tools that they're using.
Programs are essentially mathematical objects. Concepts such as program, programming language, machine, function, class, object, file, compiler, interpreter, and all the basic ingredients of programming - all of these are mathematical.
If programs can be represented as mathematical objects, and they're not a reflection of some concrete reality (we're not saying that an electromagnetic field is mathematical even if we "represent" it mathematically), we might have a reasonable suspicion that they are mathematical objects, after all. Especially when we consider that that's how they evolved historically. So the challenge, if you want to infirm this, is for you to find another essence of a program. If the mathematics is only a representation, what else is in a program?
Or what else has come up in the meantime? Because historically programs have been mathematical objects, and I hope you agree that if you write a new version of the "sort" program, it's all about mathematics and nothing else. Pick your favorite programming problem, and try to exemplify, because some of us honestly don't see these other essences of programming.
Writing a new sort program has very little to do with what *most* programmers do *most* of the time these days. Which I believe was Francis's original point, and I believe you completely missed it. In fact, one could argue that in coming up with a new sorting routine you are doing computer science, not programming at all. Can you not see the difference?
No, I sincerely can't. Maybe you can try to define it, or come up with the slightest example. The burden of proof should not be on me for the reasons I already pointed out, and you haven't addressed. A sort program was just an example. I might have missed your points altogether, but you don't do a lot to help me :) Other than negating my points for no apparently and objectively good reason. I cannot guess or have an intuition of what you and Francis are alluding to, nor do I think that such an exercise would be helpful.
Sorry, but I have addressed them. Firstly, programming is not C.S. Secondly, you seem to have difficulty differentiating the use of mathematics from the practice of mathematics. The fact that I am typing this message does not make me a linguist. Thirdly, you seem to have some strange ideas about what mathematics actually is, from the point of view of a mathematician (unless I am mixing up contributers). Fourthly, the absolute *vast* majority of professional programmers I have met, and I believe this generalizes well, have weak mathematical skills and do not tend to apply what little they do have to their daily work. This includes many people with undergraduate training in C.S. or S.Eng. (though there are exceptions, and exceptional schools). And this leads to the crux of the matter. People who program often do not do this in a mathematical way. The practice of programming has diverged from its early tight coupling to C.S. Whether or not this is a good thing is a completely different subject from that of the original page. On that page, as I understand it, Francis was asking "Well, if we aren't doing math, what are we doing?". And it is *immediately* clear to anyone who takes the time to look that what the average programmer is doing today *is not math*. This is why it *is* your burden of proof, because your assertions about the practice of programming today simply do not hold water. Francis is asking what framework you use to measure efficacy if mathematical (or C.S.) formalisms cannot help you. A valid question, I think. Finally, there are large numbers of professions that use mathematical frameworks as much as programming does, and nobody calls them mathematics. You seem to want to dilute the terminology until it is of little value. I have never heard someone say EE is math, it would be absurd. The only reason this becomes an issue is that programming is so ill-defined.
The responses to the question: "Well, if we aren't doing math, what are we doing?" is extremely simple: we are all (to a greater or lesser degree varying with individuals, and with very few people being exceptions to this rule) doing bad mathematics.
Does everyone become a mathematician at tax time? Do you consider arithmetic to be different than mathematics? Similarly, is a physicist "doing mathematics" when modelling a physical process? Mathematics can be a tool as well as a process. Much programming uses mathematics as a tool, just as a carpenter uses the metallurgy in a hammer as a tool. Using a hammer in a new way and applying new, untested stresses doesn't necessarily advance the state of metallurgy, just as a programming cobbling up a different algorithm for a specific problem doesn't necessarily advance mathematics.
This looks like a dead end of the discussion. One thing is mathematical research, another is applied mathematics. In Europe, we even have a job title Mathematical Engineer (typically a math graduate who applies advanced mathematics to solve difficult problems in other domains). Nobody on the pro-math side claimed that programmers should advance the state of mathematics (though some computer scientist did that as well).
Mathematics is not just a tool in programming, it is the essence of it - even if it is denied. A program is a mathematical object. Denying that is like a musician playing music and denying he's playing music, he might claim that he's philosophizing and notes are just a "tool". Well, nice claim but it's just not good enough. When you write a program, even if you claim you don't do mathematics, you are in fact constructing a mathematical object.
That it can be used as a tool to solve, let's say, accounting problems, is another thing altogether. But programming means just the activity of constructing a program. Requirements, validation, investment, management, negotiations and other activities in software engineering are a separate discussion.
From http://www.cs.utexas.edu/users/misra/Speeches.dir/Schlumberger.Jan02.pdf (Jayadev Misra):
See: ProgrammingIsMath, MathematicianDefinition, OoIsPragmatic, CurryHowardCorrespondence?
I am missing something here? Programming is not Maths at all. ProgrammingIsLanguage?. Syntax. Like learning about ablative absolute and gerunds. It requires vocab and logic like maths but so does learning Latin or Greek. The fact that the two have something in common fails completely IMHO to make them the same thing --AndrewCates
You are missing a lot. First of all mathematics is a lot about language. Anmd is about the same kind of languages that programming is about: formal. And is about making languages that are useful and convenient to the human mind (see BeautyIsOurBusiness), for the purpose of deriving logical properties. The claim was made that programming is essentially a sub-domain of applied mathematics.--CostinCozianu
[How about it's all a matter of perspective, and what programming is... is in the eye of the beholder. To some, programming is math, to others, it's engineering, to others, it's art, and it's entirely possible that they are all correct.]
Dammit, Costin, I hate it when you take a stance with which I disagree. It wouldn't be so bad if you were ignorant or inarticulate but, that not being the case, I have to think harder to compete. So this time I'll just wing it.
Architecture, music, photography, poetry, and farming (and, yes, programming) are certainly subject to mathematical treatments, and rigorous logical and formulaic models can be applied to [programming], but programming is about directed sequences and decisions. It can be done with digital devices (computers, et al) and analog devices (e.g. valve systems), including physical switched systems that resemble RubeGoldberg constructs.
I've actually done programming on purely mechanical systems driven by punched tape sequences and physical switches. All you had to know was "when this happens, if switch 'A' is up the light goes on and tape 'T' plays, otherwise a buzzer sounds and tape 'R' plays." Each tape was punched with codes that turned on motors, actuated relays, and blinked lights. The holes were read with mechanical fingers run by cams. The tasks were all simple, but each one was a distinct program.
The gadget was designed and built by mechanics and engineers. No one modeled it mathematically. I will concede that it could have been so modeled, but the point is that there was no formalism involved.
While it may be comfortable to assign math as an invariant attribute of programming, I submit that this is a little like asserting that musicians do math because of the clear formulaic relationships in music.
I have to disagree with "ProgrammingIsMath" although I can agree that the separation is not entirely clean. -- GarryHamilton
Now, Garry, I'm honored by your worrying about being in disgareement with me, but I'd like to remind you that I am an extremely unimportant wiki contributor, and in this particular discussion I am trying to defend/reinterpret a point of view belonging to much more notable persons. Speaking of which, I wouldn't bother to recycle these things because others provided those arguments much better than me, unless I thought it useful for these arguments to be made in a language and style appropriate for the wiki audience. So given this MeaCulpa in advance, I would note that your argument and counterexamples suffer serious flaws, not the least of which is that your counterexample is not.
Although I said it before, it doesn't take mathematicians to perform math just like it doesn't take a conservatory formal study to play music. So you think you build some software that nobody modeled mathematically. Still that software was a useful mathematical object. Just like a gypsy player can play a music that nobody wrote the notes for. It doesn't make that less than music (even beautiful music at times). There's this implied or derived message that people affirming the "mathematicality" of programming either want or may inadvertently cause taking away something from people coming to programming from other backgrounds. Well, there's something to this point, but not quite. I may come back to further elaborate, but the point was that your counterexample doesn't counter the argument. Plus programming on mechanical systems, well, that was exactly the point of EwDijkstra and the introduction to DisciplineOfProgramming. Mechanics, electronics, quantum physics, chemistry, the physical computational device just does not really count, as long as it implements an abstract model that is well understood.
Now going back to Music. Describing music is apparently not formalizable, or at least not yet. That's the reason why we have famous conductors and less than famous conductors and the same partiture interpreted by two different orchestras can sound very different. Plus there's music that cannot be transcribed: for example, although KeithJarrett? published the partiture for his famous Koln concert he refers to the audio recording as the definitive description of the music: http://www.eecs.umich.edu/~lnewton/music/KolnConcert.html. Well, audio-tapes are not application of formal languages, programming source code is. So here it goes your music analogy. What else ? --Costin
Hmmm. I see. Since the programming language itself is formally described, then the application of such a language imparts this "math nature" to the activity itself. I'm still not on board with this, although I can see why the assertion is attractive.
I came to programming through a completely different discipline, telex communications. I found that, to the degree that I could describe the problem domain, I could code representations of the "machinery and materials" of that domain. I had coded a program to read and write messages through a serial port and a companion full-screen text editor before I encountered the words "parameter" or "function."
I borrowed heavily from the paper systems in use to model the message handling stuff, just modeling in "electronic clay" (AssemblyLanguage, as that was all I knew) what I was seeing around me. I would have been flattered to know that what I was doing was any kind of math.
I have found that, regardless of the language, what I do is describe the domain and then render that description in code, without recourse to anything like a formula. Yes, occasionally there is math, but it's almost always incidental.
My 2c: No. When I program, I am building useful artifacts.
After reading IsProgrammingMath and ProgrammingIsMath, what I'd have to add is the best programmers I've worked with have had backgrounds in Applied Mathematics. CS programmes that are weak in maths seem to produce poor programmers. Here's to higher order, functional, and appreciating programming as applied or computational mathematics, and that maths is the best modelling language produced by mankind.
See also DoesMathHaveStrings
EditText of this page
(last edited October 3, 2014)
or FindPage with title or text search