There's a quotation by Alan J. Perlis that says:
There are two ways to write error-free programs; only the third one works.
I recently heard this quote from my friend, and was unable to understand the deeper meaning behind it.
What is Perlis talking about here?
It means there are really no error-free programs. A profound quote about ways to avoid errors with an error itself is parody.
I'll answer with another quote...
A strange game. The only winning move is not to play.
;-)
As many other answers have already pointed out, there is no way to write an error-free program.
But what I'd like to point out is the quote's potential meta nature. It's essentially an out of bounds error. In the first statement, he defines the universe or "list" having only two possibilities or elements. Yet in the second statement, he makes reference to a third. Which is absurd! Illegal even! A third element given a two element boundary is itself an error.
Truly profound in that the quote is able to demonstrate the very essence to which it is referring.
This means that all non-trivial programs will have bugs. It's just a funny way of saying there's no way to write an error-free program.
It s possible to write error-free programs, even non-trivial ones and even prove them correct. Consider for example, languages like Coq, Epigram or Agda where this is done.
The halting problem states that it's not possible to do this for the general program.
This reminds me of a nerd shirt I saw: There are 10 types of people in the world. Those who know binary and those who don't.
It could also be a play on the fact that sometimes lists are 0 indexed. $var = array('First','Second','Third'); And you can access this list as such: $var[0] = 'First' $var[1] = 'Second' $var[2] = 'Third'
So the literal array index 2 points to the "Third" index.
This is already explained in other words, but not as clearly as I think it should be. It simply means you will try both ways, they will have errors, and finally you will fix your bugs and have an error-free program. Compare with another quote:
The only way for errors to occur in a program is by being put there by the author. No other mechanisms are known. Programs can't acquire bugs by sitting around with other buggy programs. --Harlan Mills
(Alternatively, you could read this as Pierre said (which I think is a stretch). (The third way, which does not exist in the domain, works.) Like I said, it's a a stretch, but true.
This is the same quote my dad use to tell me when I make excuses. The saying tends to go like : "There are 3 sides to a story. Their side, Your side, and the right/true/correct side".
Putting this into context with development (and being a software tester by prof. ), I would say since there are so many ways to code something it would make sense to go with "There's 3 sides to coding. Your code, Their code, and the Refactored code."
I think this is because programmers/developers tend to refactor once the product is getting stable which is mostly too late, but most of the time the refactor is done to improve something that you and buddy did not do so well in the first place.
Hope this helps.
I think, technically speaking, that you could write a error free non-trivial program, but due to the Halting Problem it’s impossible prove that it’s error free. So, one must work under the assumption that all programs have bugs since it’s impossible to prove otherwise.
http://en.wikipedia.org/wiki/Halting_problem
Update: You can prove a particular algorithm will return the right answers, but that’s not the same thing as proving it’s totally correct. http://en.wikipedia.org/wiki/Correctness_(computer_science)
However, my point was that the quote is referring to the fact that one must assume a program always has bugs and trying to explain why that is the case. http://en.wikipedia.org/wiki/Software_bug#Bug_management
As additional insight, the "two ways" might be a reference to this quote by Tony Hoare:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.
Meditate on that a little and you'll see he's saying the same thing: if your piece of software is non-trivial, it has bugs (but complicate it enough and they won't be obvious bugs).
