Hacker News Reader

Mathematics is also a "communication language with really strict rules".

In one sense, programming often uses math. And math often uses programming. But, in a deeper sense, programming is math and math is programming. They're just different views on the same underlying ideas. They're different fields of study mainly because the priorities are so different.

Of course, this doesn't mean it makes sense to map Objective-C programming onto some "level" of math. For one, the whole math scale is completely arbitrary--who is to say that abstract algebra is more advanced than calculus? They're orthogonal. Moreover, Objective-C is in a part of programming which has really, really different priorities from normal mathematics. I still maintain that they're fundamentally related, but you're doing such different things that there's very little practical overlap. Certainly not enough to translate to some common sub-field of mathematics, much less one taught to high-schoolers!

Mathematics can easily be applied to anything from cooking to theoretical physics. That doesn't make any of these things math or the other way around. You can use math to solve a programming problem (perhaps to a greater extent than in cooking) and you can express many of the problems in mathematical terms, but in the end math is an abstract tool and programming is not.

No, the relationship between programming and mathematics is much deeper than that. In particular, it's not a relationship to the sort of mathematics you are thinking of--not the sort that you would use to solve a concrete problem or apply to physics or cooking.

Rather, the relationship is between what a program is and the very foundations of mathematics--formal logic. In particular, a programming language is a formal system exactly the same way a logic is a formal system. A mathematical proof is really the same sort of object as a computer program. It just turns out that the goals behind the two are different, so the rules of the formal system (either a logic or a programming language) behave very differently. But, at a high level, it's the same idea.

In fact, the way we ascribe semantics to programs and programming languages is analogous to how we can reason about proofs and logics. As a rough comparison, denotational semantics are like model theory and operational semantics are (sort of) like proof theory.

That said, for the most part, this relationship to mathematics is actually orthogonal to the sort of math you would use in writing a program. Linear algebra, geometry, group theory and so on are great for applications but not what I was talking about. Instead, the mathematics I was alluding to only comes out when you get sufficiently "meta" and start writing programs that operate on other programs--static analysis, verification and so on.

I'm not sure what you mean by "abstract tool", but programming is just as much an abstract tool as mathematics. The only difference is that we have some handy hardware for realizing the former.

This is philosophical mumbo-jumbo.

When people program, they (usually) don't do math. And that's it.

The fact that you can view a programming language as a formal system, and the fact that computer programs can be viewed as mathematical proofs of mostly totally uninteresting propositions, doesn't magically turn programmers into mathematicians, just as the fact that the brain can be viewed as a chemical and physical system doesn't turn every thought into a chemical experiment, and each thinking person into a chemist.

Saying otherwise is just an abuse of language.

It depends on what you mean by "do math". Both a proof and a program are just syntactic manipulations following a particular set of rules. The exact rules differ, but the underlying system doesn't.

Proving something in a low-level way--just following inference rules--and executing a program are basically the same things. This is abundantly clear if you formally study operational semantics, but even people who haven't still think operationally. Of course, nobody thinks purely operationally, but then again, practising mathematicians also rely on some poorly defined "intuition".

I never claimed this makes programmers mathematicians. It doesn't. Both fiddle around with formal systems, but the goals and the actual practice differ enough to make the two fairly distinct. But they're still related and we still use the same tools to analyze both: automated theorem provers, type theory, Curry-Howard...

The fact that I can bring advancements from formal logic to bear on analyzing programming languages and the fact that I can bring advancements from programming languages to analyze proofs means this is no mere "philosophical mumbo-jumbo". This includes all sorts of things you probably think completely removed from mathematics, like verifying properties of drivers or automated debugging.

Not only is it a deep relationship to think about, it's one we regularly exploit. Even if most programmers do not acknowledge it, it exists. Really, you're saying more about the state of programmers' education than anything else.

Besides, you never really made much of a point. You made a statement and a poor analogy in its support and accused me of "abuse of language", but never said anything substantial.

Quick comment: I think people are emphasizing too much the 'logic' of mathematics, over its content. Mathematics is NOT about rigorous thinking and logical patterns (unless of course you study logic). It is much freer, pattern-based, and intuitionistic than that. It just so happens that rigorous/logical argumentation is the best way to communicate mathematics.

In this sense, programming is much more algorithmic, and hence I would argue, not particularly like math (the content) at all.

If the question of the poll was "My son eats carrots, what level of piano-playing does it equal to?", would you then say that eating carrots and playing the piano are fundamentally the same, because they are both reducible to physical laws and are just manifestation of different kinds of brain activity?

We all get it, and we all agree - programs can be viewed as a subset of mathematics. Every CS undergrad knows this. It is conceptually misguided to view this piece of information as revealing anything deep about what programmers do, just as it is conceptually misguided to view our ability to reduce both fishing and singing to brain activity (or to reduce everything to the laws of physics) as saying anything deep about what fishermen do. It doesn't became any less misguided simply because examples exist where math can be directly applied to programming, and vice versa.

It is philosophical mumbo-jumbo because you are taking two activities with clearly distinct meaning in everyday language, and instead of simply acknowledging that we can invent a new meaning for them under which they are the same, you instead convince yourself that this new invented meaning is the only fundamentally correct one (or somehow "deeper"), and that it also has the power to show that the 'everyday' meaning is wrong. But you are not showing anything about things we already know - you are simply presenting new, different ways of looking at them, that bear little relevance to the question at hand (A circle is topologically equivalent to a square. Does it mean that our 'old' preconceptions of difference between circles and squares are now wrong?).

The activity of doing mathematics, as those words are used in everyday language, is different from the activity of programming, even if in some senses (perhaps in more than one) they can be viewed as the same. The activity of running is different from the activity of fishing, even though they can be reduced to similar building blocks.

I do not object to the mathematical connections you present, I object to the philosophical interpretation you give to them.

> When people program, they (usually) don't do math. And that's it.

I disagree. Whenever you implement an algorithm, you build a proof of correctness in your mind. If you reasoned about your program and are convinced that it handles all corner cases properly, then it would only be a formality to write this proof down. If you can't easily do that, then you can't possibly be certain that your program has no bugs.

In practice, you don't bother with this kind of thing unless you are writing extremely complex algorithms, of course, but that doesn't change the underlying principle.

If you don't usually bother with this kind of thing, it means that you don't usually do this kind of math when you program.

Algorithms researchers may be employing the mathematics of computing depending upon the particular subject and scope of study. That body of non-CS academics (mathematicians, physical scientists, and engineers) who use mathematics daily as a primary component of their research are doing math when they write programs--but not necessarily the mathematics of computing.

Almost everybody else who writes programs isn't thinking in terms of mathematics, be it of computing or any other thing. Asking "what level of mathematics is this equivalent to" is therefore kind of a nonsense question--it has no real answer, because it implies there's a legitimate comparison to be made when there isn't.

I would like to jump in here and agree you. You can program some really cool stuff with a very minimal knowledge of math.

Anything beyond understanding some basic Algebra and Geometry concepts isn't required in order to program.

Most of the stuff (at least that I have run into) is just organizing data into a visual (like a report or graph) that will allow someone to make informed decisions. This only requires basic math (averages, percentages). If you can filter data, perform basic math functions on that data, spit it back out onto a report or graph then you can program for the majority of business needs.

The only time advance mathematics would be needed is if you are coding for scientists/mathematicians that want to apply advanced math to their data.

I'm not sure there is such a difference between mathematics and an "algorithm". Time can be factored out of a process. A process can be represented as a sequence of objects. Take a function taking some arguments, one can describe this function in it's entirety by describing each sequence of objects generated by each possible input. Then if one wants to recreate the operation of the function one simply looks up the appropriate sequence of objects. A function then becomes a mathematical object in the abstract. In the same way some mathematical object can be described as the result of some process. Take the definition of the natural numbers, an object 0 is defined and a successor to this object to the next object is defined. This operation defined recursively sets up the whole natural numbers. The description of the natural numbers is the result of the evaluation of this function recursively applied, or the infinite application of this function. Since the study of mathematics is the study of these abstract objects and these objects encapsulate those objects which we can produce in the physical world through some process, mathematics by definition is a study of programming. Whether the mathematics explored by mainstream mathematics is the same mathematics explored by the code monkey is perhaps relevant. But the duality exists. In essence a study of physical reality is the study of those mathematical objects which can be constructed by the processes extant in that reality. So analysis of anything is mathematics, it just may not be the kind of mathematics we usually associate with the word.

    > I'm not sure there is such a difference between mathematics and an "algorithm"

Well, then we fundamentally disagree. An algorithm isn't math. Arguing about an algorithm mathematically, or even analyzing it at all as an algorithm might be related to mathematics, but the algorithm itself isn't.

I have an MSc in mathematics and a strong interest in this area. I would be happy if you were to show me that I am wrong

This has nothing to do with mathematics or with your MSc, this is a a philosophical discussion about the meaning of words.

Is there anything concrete you can say in response to my argument, or is this it?

If a process can be represented as such and such, and then this in turn can be represented as something else, and then eventually after this possibly-long chain of transformations we reach something mathematical, then it is that something which is mathematical, and not what we started with.

This is like saying: "There isn't such a difference between neurology and physics. A brain can be viewed as a collection of cells, which in turn can be viewed as a collection of organic molecules, which in turn can be viewed as a collection of particles, and physics studies particles. So neurology = physics. Q.E.D"

But what is missing here is the realization that it is exactly our decision not to view the brain as a collection of particles which gives neurology it's meaning. The decision to view something as something else is not trivial. When you choose to view X as Y, it is no longer X you are talking about.

You wrote: "...it just may not be the kind of mathematics we usually associate with the word."

But it is precisely what we "usually associate with the word" which gives meaning to words. If in this "usual" meaning it is wrong to say that mathematics is the study of algorithms, then mathematics isn't the study of algorithms.

When we want to create new precise definitions to old words, what we are trying to do is to formulate a description that fits as best as possible our everyday use of this word. If we ended up with a definition of math that says "the analysis of everything is math", the only logical conclusion is that we did a pretty bad job.

Beg to differ:

http://www.amazon.com/Our-Mathematical-Universe-Ultimate-Rea...

I'm sure that if you meant to argue with anything I said, you'd make a greater effort than posting a link to a book you enjoyed. But just in case: I believe that mathematics is able to describe very fundamental concepts of our universe. That doesn't mean that everything in the world _is_ mathematics, for the same reasons that the fact that you can describe many things in spoken words don't make them spoken words.

I think one major difference is that programming languages are mostly imperative while mathematical statements are more declarative. When you're solving a mathematical equation, you are typically given a statement which you need to transform into another form. How you do that is less important than proving that the alternate form is valid given the equation. You declare the problem and the solution you want to solve for first, and there may be multiple ways to get there, you just need to show a valid way.

"Programming isn't analogous to math"

I think it's analogous to math in the sense that a programming language is a formal system, just like any logical system. The syntax is defined by formal rules, it semantics if not defined formally is strictly defined by the compiler implementation or hardware.

Actually, the link between programming and proving as been characterized by the "curry-howard isomorphism" that says that a program is a proof of his type. In that sense, programming = writing a proof.

For instance, in ML : the program "fun (x,y) -> x" is a proof of the proposition "A and B => A". This idea can be extended to more complex types/propositions (see the Coq proof assistant for instance).

That being said, writing programs usually require different set of skills than doing mathematics. The best programmers are not always the best mathematicians and conversely. To me difference shows especially for big complex software, rather than smart algorithms in programming contests for instance.

"If your son (or anyone) understands variables, assignment and adding them together, they fundamentally understand Algebra."

This seems like it should be so, but real world experience tells me it is not. Understanding how someone can understand one and not the other is beyond me, but its exceptionally common and a huge stumbling block for me to teach people programming.

The fact that we are usually writing relations in algebra, but instruction statements in programming is really quite significant, even if they look similar.

Thanks for that link. One thing caught my eye: the algorithm starts with a depth first walk of the graph. Reading that, I thought "that n must be the number of edges". However, theorem 1 in section 6 starts with "Given a graph G with n vertices" and the proof starts with "The depth first search [...] implemented with well-known linear time algorithms."

I don't know that well-known algorithm, and neither does Google, it seems. At least, I can't find it, and can't see how it would work. Now, section 5 has a procedure that requires <= 3n-5 edges for a graph with n vertices. Is that supposed to hold throughout? If so, what's that 3n-5 about? Are there well-known theorems or algorithms to disprove planar it's for such graphs?

Algebra, at least in the high-school algebra sense[1], is just really strict rules for communicating points on a (line, plane, etc). It is a bunch of operations for finding an equivalent way of stating the same thing, and some rules for reasoning about those points. For example, finding the roots of a function is nothing more than manipulating a statement until you find out where y = 0.

In a direct use way - any time you program with conditionals you are directly applying boolean algebra. There is no way around it - you have to understand how the basic rules of boolean algebra work. e.g. how does 'not' distribute, how do "AND" and "OR" work, etc. And it certainly helps with simplifying code if you can apply DeMorgan's law or distribute your conditions differently. There is a reason it's called refactoring code - it is just applying the algebra rules (usually the boolean ones) to program flow.

Similarly, but a bit more abstract, string primitive operations are an algebra for working with series of characters. They are equally strict, although not the exact same rules as those for points on a curve. For instance associativity doesn't apply to addition. Multiplication isn't defined for some languages, and there are different ways to define it for other languages (does it distribute, etc). This isn't even that abstract...

Given a string, solve for the character at position x. This is not really different than given a function, solve for the position at x.

Given a function, and value y, solve for x. Its the same as given string, find the indices for a character.

The operations are a bit different, but the reasoning between them is exactly the same: manipulate the givens with the rules that are defined. Use the rules to find properties of the target.

[1] there are other algebras - for example ring theory algebra. It has rules that are different (mostly generalizations of basic algebra rules, but that have weird and non-intuitive results if all you know is basic high-school algebra). This sentence from the wikipedia article explains it well:

"It follows that algebra, instead of being a true branch of mathematics, appears nowadays, to be a collection of branches sharing common methods."

To add:

Programming a first person shooter requires linear algebra. Programming crypto-algorithms require discrete math.

> Programming isn't analogous to math

https://en.wikipedia.org/wiki/Curry-Howard_isomorphism

"uses math of all stages" - I don't think so! Source - post-doctorial mathematical researcher.

> If your son (or anyone) understands variables, assignment and adding them together, they fundamentally understand Algebra.

A more important part of algebra is symbol manipulation, and understanding why some manipulations are valid and others are invalid. That symbol manipulation is the core of grade-school (or trivial) algebra. Being able to 'see' how to solve a problem, and being able to abstract general rules to solve whole classes of problems, all flow from that.

Of course, there's a disconnect between using '=' to denote a state of being (the state of equality) and using '=' to denote an action (the action of assignment). As an example, 'x = x + 1' is either trivially nonsense or trivially valid. Haskell actually uses '=' in the mathematical sense, to denote a state of being, and SSA languages such as Erlang come pretty close to it, I think.