One great difficulty in the adoption of statistical methods and statistical thinking is the question of the interpretation of probability theory. Most statisticians and physicists favour the frequentist interpretation (at least according to Wikipedia), but in computer science we often see the subjective interpretation as well, mostly in its Bayesian form.
In using and understanding statistics, I believe it is crucial to consistently adhere to one interpretation of probability. In media, I have often seen frequentist statistics being presented as if it were to be interpreted subjectively. I think honest presenters of statistics must acknowledge that there is a mile-wide gap between asserting that the relative frequency of some event is high in a certain sequence, and asserting that the degree of rational belief that a certain event will happen is high. Even if everybody read "How to Lie with Statistics", I think the problem of the interpretation of probability would continue to be a source of confusion for both the general public and statisticians.
In my probability and statistics class, I was frustrated by the fact that they did not even mentioned the problem. We were simply given the Kolmogorov axioms and some set theory and told to get to work. However, I suspect this is the common case for such entry-level courses.
(1) The terminology is misleading. The author speaks of "NP problems" without further qualification, and calls these problems "hard problems". NP problems, in the sense of problems belonging to the complexity class NP, however, are not "hard" in general, because all problems in P belong to NP (this is a trivial theorem). And no problem has been shown to be in NP but outside P. He might be referring to the so-called NP-hard problems, which formally are the problems at least as hard as the hardest problems in NP. But this wouldn't make much sense, since he doesn't bring up the NP-complete problems (the only NP-hard problems we know of inside the class NP) until the end of the article.
(2) Suppose P=NP. I, for one, would see this to be a good thing. The gain in the field of e.g. combinatorial planning and scheduling would be enormous, far outweighing any loss in the field of cryptography.
In the same way that you do not need to criticize totalitarian ideologies on moral grounds - referring to faulty methods and inadequate results is quite enough - there is really no reason to condemn "non-free" software on account of the "antisocial system" that it carries with it. Whenever there is an argument of "morals", or more specifically, values, it can never conclusively be decided if not, as Finnish philosopher von Wright notes, the participants share a common value basis.
Thus, as long as Richard Stallman keeps asserting that free software should be adopted for "moral" reasons only, we may without contradiction justify ignoring his arguments by saying that we do not share a common value basis with him.
The objective (in Immanuel Kant's sense of the word) reasons to adopt open-source software are an entirely different matter, however. I believe that the word "open" rather than "free" is the key term to use when speaking of the superiority of (GNU/)Linux and *BSD as opposed to proprietary operating systems. The former word is a mere description, allowing us to examine merit independent of anybody's whim; the latter speaks to our morals and convictions, which can never be intersubjective.
Even in languages which do not have the freedom/price ambiguity of English, the word 'free' has been so severely misused, got so value-overloaded, that it should, I believe, be avoided in any rational discussion, in any language.
My assessment of open source is that it is, at its core, a software development methodology; one that is closely related to methodology of science.
Now, if this assessment is even half accurate, it would be quite absurd to blame the failure of a certain business model to the development methodology it favoured above others. In fact, methodologies cannot themselves be attributed any value; they may, at most, have different degrees of fitness for a particular purpose.
I think labeling a certain business model or a company as "open-source" is not only incorrect - it causes a lot of unneeded confusion. It is easy to get the impression that when an "open-source" company fails, it is a blow to the whole "open-source community", when this clearly cannot be the case when we view open source as a development methodology.
I know that Eric Raymond, Bruce Perens and others have done a lot of work to make us think warm, fuzzy, positive thoughts when hearing the words "open source", and I understand their reasons for doing it.
However, one of the drawbacks of using that kind of tactics is that we will continue to see "open source" applied where it does not belong, taking blame where there is none to be taken.
A monk asked Joshu, "Does this company have the open-source nature?" Joshu retorted, "Mu!"
Cringely remarks repeatedly that Torvalds and other open-source developers are "giving away software for free". This view is all too common among those who comment on business and open source. It implies that every kind of software is some soft of product, which you can (and should) package and sell. Most open-source software can be more accurately described as "evolving entities" rather than products.
Cringely says that Ballmer has misunderstood open source. But by using the expression of "giving away" things, he doesn't really contribute to a better understanding of open source himself.
When scientists publish theories in a widely available scientific journal, it would be absurd to say that they are "giving away their theories for free".
I think the analogy is appropriate, because scientists and open-source developers have roughly the same goals when offering their work "to the world". They want peer-review (although not exclusively, of course).
The personal conviction that your software is functional and bug-free is not in any way an argument that it is. Holding the opposite would be confusing psychology with logic. That is why scientists and programmers need to expose their theories and software, respectively, to critique from others in (and outside) their field; to find flaws they themselves are unable to discern.
So, the correct answer to the question "Why should I use your software?" is:
"It has been severely tested in all areas it is expected to work, by people all over the world, never failing a test even once".
Slashdot Mirror
One great difficulty in the adoption of statistical methods and statistical thinking is the question of the interpretation of probability theory. Most statisticians and physicists favour the frequentist interpretation (at least according to Wikipedia), but in computer science we often see the subjective interpretation as well, mostly in its Bayesian form.
In using and understanding statistics, I believe it is crucial to consistently adhere to one interpretation of probability. In media, I have often seen frequentist statistics being presented as if it were to be interpreted subjectively. I think honest presenters of statistics must acknowledge that there is a mile-wide gap between asserting that the relative frequency of some event is high in a certain sequence, and asserting that the degree of rational belief that a certain event will happen is high. Even if everybody read "How to Lie with Statistics", I think the problem of the interpretation of probability would continue to be a source of confusion for both the general public and statisticians.
In my probability and statistics class, I was frustrated by the fact that they did not even mentioned the problem. We were simply given the Kolmogorov axioms and some set theory and told to get to work. However, I suspect this is the common case for such entry-level courses.
(1) The terminology is misleading. The author speaks of "NP problems" without further qualification, and calls these problems "hard problems". NP problems, in the sense of problems belonging to the complexity class NP, however, are not "hard" in general, because all problems in P belong to NP (this is a trivial theorem). And no problem has been shown to be in NP but outside P. He might be referring to the so-called NP-hard problems, which formally are the problems at least as hard as the hardest problems in NP. But this wouldn't make much sense, since he doesn't bring up the NP-complete problems (the only NP-hard problems we know of inside the class NP) until the end of the article.
(2) Suppose P=NP. I, for one, would see this to be a good thing. The gain in the field of e.g. combinatorial planning and scheduling would be enormous, far outweighing any loss in the field of cryptography.
In the same way that you do not need to criticize totalitarian ideologies on moral grounds - referring to faulty methods and inadequate results is quite enough - there is really no reason to condemn "non-free" software on account of the "antisocial system" that it carries with it. Whenever there is an argument of "morals", or more specifically, values, it can never conclusively be decided if not, as Finnish philosopher von Wright notes, the participants share a common value basis.
Thus, as long as Richard Stallman keeps asserting that free software should be adopted for "moral" reasons only, we may without contradiction justify ignoring his arguments by saying that we do not share a common value basis with him.
The objective (in Immanuel Kant's sense of the word) reasons to adopt open-source software are an entirely different matter, however. I believe that the word "open" rather than "free" is the key term to use when speaking of the superiority of (GNU/)Linux and *BSD as opposed to proprietary operating systems. The former word is a mere description, allowing us to examine merit independent of anybody's whim; the latter speaks to our morals and convictions, which can never be intersubjective.
Even in languages which do not have the freedom/price ambiguity of English, the word 'free' has been so severely misused, got so value-overloaded, that it should, I believe, be avoided in any rational discussion, in any language.
My assessment of open source is that it is, at its core, a software development methodology; one that is closely related to methodology of science.
Now, if this assessment is even half accurate, it would be quite absurd to blame the failure of a certain business model to the development methodology it favoured above others. In fact, methodologies cannot themselves be attributed any value; they may, at most, have different degrees of fitness for a particular purpose.
I think labeling a certain business model or a company as "open-source" is not only incorrect - it causes a lot of unneeded confusion. It is easy to get the impression that when an "open-source" company fails, it is a blow to the whole "open-source community", when this clearly cannot be the case when we view open source as a development methodology.
I know that Eric Raymond, Bruce Perens and others have done a lot of work to make us think warm, fuzzy, positive thoughts when hearing the words "open source", and I understand their reasons for doing it. However, one of the drawbacks of using that kind of tactics is that we will continue to see "open source" applied where it does not belong, taking blame where there is none to be taken.
A monk asked Joshu, "Does this company have the open-source nature?" Joshu retorted, "Mu!"
Cringely remarks repeatedly that Torvalds and other open-source developers are "giving away software for free". This view is all too common among those who comment on business and open source. It implies that every kind of software is some soft of product, which you can (and should) package and sell. Most open-source software can be more accurately described as "evolving entities" rather than products.
Cringely says that Ballmer has misunderstood open source. But by using the expression of "giving away" things, he doesn't really contribute to a better understanding of open source himself.
When scientists publish theories in a widely available scientific journal, it would be absurd to say that they are "giving away their theories for free".
I think the analogy is appropriate, because scientists and open-source developers have roughly the same goals when offering their work "to the world". They want peer-review (although not exclusively, of course).
So, the correct answer to the question "Why should I use your software?" is: "It has been severely tested in all areas it is expected to work, by people all over the world, never failing a test even once".The personal conviction that your software is functional and bug-free is not in any way an argument that it is. Holding the opposite would be confusing psychology with logic. That is why scientists and programmers need to expose their theories and software, respectively, to critique from others in (and outside) their field; to find flaws they themselves are unable to discern.