Comment by seliopou | Hacker News Reader

Comment by seliopou | Hacker News Reader

Parent Full thread

Not the case. The same argument does not apply because of the nature of mathematical, and to a certain extent scientific. All three--mathematics, science, and computing (programming)--are similar in that their primary currency is knowledge that can be concisely described and embodied in instruments (tools), either of which can then be used by others without too much of a concern for where that knowledge or instrument came from as long as there's a good instruction manual nearby. The knowledge and instruments are used to create more knowledge, which is embodied in more instruments, and the cycle continues on and on etc.

The difference between computing and mathematics is the form that the knowledge and the instruments take. In mathematics, the concepts you're dealing with (or inventing, since I'm not a mathematical realist) are very clean and they stack well. You also have virtually no instruments to speak of. As a mathematician, it's not too common that you reduce your theories to practice. That's something that's left to the lesser sciences, such as computing.

In computing, the relationship between between knowledge and instruments is that of identity. At the very least, the two are conflated in casual discussion. More concretely, the "knowledge" of computing is typically a model of some problem domain and the the instruments are software, which in turn manipulate the physical world (that's what your JavaScript is doing) in order to perform some task or measurement in service of solving some problem in your domain.

So in mathematics, you have no correspondence between knowledge and instruments to do deal with. In computing, that's all you're dealing with except people are only really interested in the knowledge as its embodiment in the instruments. Static typing ensures that some sliver of that knowledge is explicit and checked. It doesn't mean it corresponds to the thing in your brain, but it does ensure that whatever's written down is embodied in your code. Mathematicians have no such constraints to deal with. They would if the proofs that they wrote were formal proofs, but they're not. Most, if not all, mathematicians know this. Most programmers, though, don't.

> Static typing ensures that some sliver of that knowledge is explicit and checked.

No. Testing ensures that the knowledge is checked. As in: run experiments. Empirical evidence. Static typing only checks one set of assumptions against another set of assumptions. Don't get me wrong, this is better than nothing. But the only real check is actually running the code, getting empirical evidence.

In every other engineering discipline, math is seen as a tool, simulations are cost saving measure because running experiments for everything is too expensive. Only in the discipline where gathering empirical evidence is actually generally cheaper than trying to prove things (with mostly dubious value) is there this odd notion that using math is superior to running the experiment.

If flying planes or running wind tunnel tests were as quick and cheap as running computer simulations, there would be no more computer simulations in aviation.

Compare Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it."

First,

> some sliver

Second, I for the most part agree with you in the ways that are relevant to the point you're trying to make. However, the knowledge/tool distinction is a vague (in that they may fall on a spectrum) and ambiguous (both words tend to be moving targets), which is why I chose the term instrument instead. Mathematics is a tool only in the sense that it is knowledge that is applied towards some benefit, e.g., efficiency. Also,

> Compare Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it."

This is again "proof" in the day-to-day mathematical sense of a convincing argument, not in the formal sense for writing down an expression per line such that each line can be logically deduced from some preceding lines through the the use of axioms. A type checker is literally a search procedure through the space of derivation trees to find a formal proof that this term has this type.

Type checking is a conservative analysis, and the type correctness of a program is undecidable. But you can still rely on the knowledge generated by your type checker without having to run your program. Among other things, this allows you to optimize your program automatically.

> "proof" in the day-to-day mathematical sense of a convincing argument

IIRC, that is the most that a so-called "proof" can ever be. I remember reading Carl Friedrich von Weizsäcker's "Aufbau der Physik"[1] in my younger years, and being somewhat flabbergasted when he starts by justifying classical logic, which he needs to do because later he talks about quantum logic, which is different.

Up to that point, it had never occurred to me to justify logic empirically, but now I can't imagine naively accepting it. That means that empirical evidence always trumps. Everything. If we find logical rules that we assume violated in the real world, we have to deal with it, not deny reality. Just like we had to accept that other aspects of the world we held as self-evident were not just theoretically contingent, but actually turned out not to be true.

> not in the formal sense for writing down an expression per line

> such that each line can be logically deduced from some preceding

> lines through the the use of axioms.

Hmm...that's how we always did (simple) mathematical proofs: line-by-line, with axioms or theorems justifying the transformation from line to line. Last time I checked, so-called "machine-proofs" are definitely seen as different by mathematicians, yes, but they are less well-respected, not more so. Has this changed?

[1] http://www.amazon.de/Aufbau-Physik-Carl-Friedrich-Weizsäcker...

Actually, empirical observation depends on the correctness of basic logic, which must therefore precede it. You can't do experiments without having a logical framework that allows you to interpret their results. You can certainly find people who've convinced themselves that they need to empirically check math. i.e. check that 30x100 = 3x1000 by rearranging beans on their kitchen floor. I wouldn't hire anyone who did that to paint my bathroom, though.

That's the fallacy of uncritical rationalism. See Popper.

I prove mathematical properties purely for the sake of proving them. The fact that they have any bearing on the real world is a mildly interesting diversion. Given this frame of reference, empirical evidence almost never enters the picture when justifying a proof. Indeed, empirical evidence is necessarily finite, whilst even some of the most simple proofs reference the infinite.

> I prove mathematical properties purely for the sake of proving them

Good for you. I also think pure maths can be a fun diversion.

> The fact that they have any bearing on the real world is a mildly interesting diversion.

Well, computer "science" is primarily an engineering discipline. It is therefore primarily, if not entirely, about having bearing on the real world. (And even if it were a "science", which it largely isn't, that would still be the case).

> Given this frame of reference, empirical evidence almost never enters the picture when justifying a proof.

Given this frame of reference, your proof is of no relevance to software, which was exactly my point: yes, you can do these proofs, but they are largely irrelevant, and even if relevant always subsidiary to empirical evidence.

> Indeed, empirical evidence is necessarily finite, whilst even some of the most simple proofs reference the infinite.

How do you know that while these proofs reference the infinite, they are actually applicable to the infinite? The answer is: you don't and you can't. You can only assume that the proof mechanisms you use actually do not break down. Now I am certainly convinced (= I believe) that induction will continue to work for all N if I prove 1 and N -> N+1, but I have only empirical evidence for small N to justify that belief. And if we found an M where it didn't, what then?

And of course, there always have been (and probably always will be) "proofs" that were later shown not to be correct, just like physical "laws" that turned out not to be laws. All knowledge is contingent, especially all-quantified knowledge.

And I have to admit that I find the naive/rigid belief (it is no more than that) in the absolute power of proofs...charming :-)

> Well, computer "science" is primarily an engineering discipline.

I would say that software engineering was the engineering discipline, and computer science a mathematical discipline.

My point was that the proof itself is not subsidiary to empirical evidence, only its application is, and in my eyes, there is merit in the proof, free from its application to the "real world", for example as a lemma to another proof. Consider it a form of separation of concerns: whilst I prove a theorem, I am not concerned with how it mirrors the observable world, but in order to apply it, of course I must ensure that its assumptions can be reliably observed. In this way, our "beliefs" are limited and do not taint the logic of the proof itself.

> How do you know that while these proofs reference the infinite, they are actually applicable to the infinite?

Which brings us to your next point: I do not know, I simply believe it to be true because it is convenient to do so. My point is that this belief or its refutation does not affect the worthiness of the proof, only that of its application.

I actually do not believe in the absolute power of proof, I don't think it is something you can get away with believing once presented with all the facts. I hope I've explained myself better in this comment though: I don't think our views are as antipodal as it first seemed.

But testing ensures no such thing, considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases. Part of the usefulness of static typing is to prevent us from having to negotiate that state space explosion head on by a priori ruling out vast swaths of potential inputs.

I think static typing and testing are much more complementary than you're giving them credit for.

> But testing ensures no such thing

Yes it does. Empirically.

>considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases

Fortunately, it is also not necessary, as numerous studies have found.

>I think static typing and testing are much more complementary than you're giving them credit for.

I totally agree that they are complementary. I find static typing to be most useful as checked documentation (for which, unlike the safety aspects, there is actual empirical evidence). Also, it makes various optimizations easy/cheap/predictable, which I find highly valuable.

Finally, it does help a little bit with correctness, though far less than what many people claim.

However, it also has costs that are not insignificant, in slowing down exploratory programming, compile-time costs, brittleness of designs and often code expansion / productivity.

More importantly, it appears to harm compositionality/reuse, at least at our current level of understanding. Both Unix Pipes and Filters and the Web, arguably the most successful reuse mechanisms in the history of software, are dynamically and somewhat loosely typed. In addition, personal computing was invented in around 20KLOC using Smalltalk, a dynamically typed OO language.

> > But testing ensures no such thing

> Yes it does. Empirically.

Your claim was "Testing ensures that the knowledge is checked." And, yes, testing ensures that the knowledge is checked - by the test.

mrbrowning's claim is that "Static typing ensures that some sliver of that knowledge is explicit and checked." That's also true (despite your reply of "No"). And note mrbrowning's use of the word "explicit". Type knowledge is more explicit than a test. It ensures that this data structure is an instance of the specified type. A test proves that in this set of circumstances this data structure behaves the way we expect, which is a weaker proof.

> It ensures that this data structure is an instance of the specified type.

But downcasts are unsafe.

> >considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases > > Fortunately, it is also not necessary, as numerous studies have found.

If you know something about how some function or module works and you check the right corner cases, the only way a bug could be hiding in some of the other input combinations is if it were deliberately planted in the form of extra code, like "if the inputs are specifically x, y and z, then misbehave such and such".

For instance if we know that a 32 bit adder is made up of bunch of full adders, there are certain bit patterns we can use which tell us that the adders are working properly individually, and that they are hooked up together right. We don't have to test every A + B = C triplet, blackbox style.

Reply on news.ycombinator.com