[deleted]
A three-page paper that shook philosophy, with lessons for software engineers
31–40 of 185 posts
Re: A three-page paper that shook philosophy, with lessons for software engineers
#32This are called false positives and are a normal occurrence in the life of a software developer. That's why when testing the root-cause you should test for a false positive as well.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#33I think it helps to look at the mind as a probabilistic survival engine than some truth engine. If there appears to be a cow in a random field the odds are extremely low that someone put a papier mache cow there. If there’s something that has 50 % chance of being a snake you panic and run because that’s a 50 % chance of dying. In the case of the authors bug yes the change he introduced had a good probability of being…
I like the term "probabilistic survival engine". It explains a lot of phenomena in social trends, religion, politics, and even the practice of science.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#34> A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare. I beg to differ. Besides the examples in programming the author gave, I can very easily think of examples in medicine, police work (e.g. regarding suspects), accounting, and so on...
Well, why not write them down for us?!
Re: A three-page paper that shook philosophy, with lessons for software engineers
#35The propensity for mistaking belief for facts certainly take daily hits as a software developer. "How come this simple thing isn't working? I thought of everything didn't I?". After a while you are forced to realize that belief isn't the same as reality. It seems insights like this don't easily translate into other domains though, like relationships, dearly held political views etc. We prefer to think of them as base…
it does seem to be a 24/7 zen practice.. i'm nearly always wrong so let's focus on checking every assumption with an open mind
Re: A three-page paper that shook philosophy, with lessons for software engineers
#36This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are: * expected output from a known input (intention) * unexpected output from a known input (defect) * expected output from an unknown inp…
How is 2 & 3 from above different from 4? An unknown input producing correct results is still a problem - the unknown input is the problem. Therefore, i postitulate that anytime an unknown input is possible, the software is defective.
My application is a code beautifier that receives code samples as input. I cannot know of every possible combination of code samples. This does not necessarily mean the application is defective. A defective state is unwanted output.
Another way to think about this is that the more open a system is the more useful and risky it is. It is useful because it can do more while tolerating less terse requirements upon the user. It increases risk because there is more to test and less certainty the user will get what they want. Part of that risk is that its hard to guess at what users want as sometimes the users aren't even sure of what they want.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#37To me this seems unhelpful. I'd say there is no "knowledge"; there's only belief. And if you defined knowledge as "justified true belief" then you couldn't apply the definition in practice in the real world because you don't know when something is true. But that's philosophy for you: fun (for some people) but not useful.
In an epistemology class once I said to the lecturer "I don't know anything." He said "Don't you know your name?"
Re: A three-page paper that shook philosophy, with lessons for software engineers
#38I don't think the example of checking in someone else's bug is a very good one. If I checked in something that had code from other people I would see it very easily, and if I did not think there was any way my code should have affected the autocomplete then I would assume the code I checked in which was not mine broke the autocomplete.
Matching it to the example of the papier mache cow doesn't really work because the papier mache cow hides the real cow but it is very easy to see that your code was also checked in with other people's code.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#39There's a much closer analogy from software development to the cow story. The cow story is confusing because the cow that you see (A) is fake, but the real one (B) you don't know about. So your belief is not a justified true belief because although the real cow exists, the one your knowledge refers (A) to isn't the real one (B).
An intertemporal variant of this is race conditions. There have been lots of problems of the form "(1) check that /tmp/foo does not exist (2) overwrite /tmp/foo"; an attacker can drop a symlink in between those and overwrite /etc/password. The file that you checked for is not the same file as you wrote to, it just has the same name. This is an important distinction between name-based and handle-based systems.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#40This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are: * expected output from a known input (intention) * unexpected output from a known input (defect) * expected output from an unknown inp…
How is 2 & 3 from above different from 4? An unknown input producing correct results is still a problem - the unknown input is the problem. Therefore, i postitulate that anytime an unknown input is possible, the software is defective.
The entire world of AI relies on dealing with "unknown" input?