A three-page paper that shook philosophy, with lessons for software engineers • Hacker News Board

Re: A three-page paper that shook philosophy, with lessons for software engineers

#81

Post by dotancohen » Tue, Jan 15, 2019, 2:56 PM UTC

chii wrote: post #44

kstenerud wrote: post #29

Earlier quoted context omitted.

Say you write some movement software. You expect that people will move forward, left, or right. You didn't expect people to try moving backward. People start moving backward, but the software happens to do the right thing due to how it was written. Is the software defective because of your missed expectation?

Yes, i would still classify the software defective. It did not reject backwards explicitly. Just because by accident it works (i.e., the consumer of the output doesn't care) doesn't mean the defect has gone away. To be not defective, the software has to explicitly reject input that it was not designed to handle. Imagine if the software updated with some changes, and the unknown input now produces an incorrect output.…

What would "reject input that it was not designed to handle" look like for an automated car?

Re: A three-page paper that shook philosophy, with lessons for software engineers

#82

Post by el_cujo » Tue, Jan 15, 2019, 2:58 PM UTC

pwaivers wrote: post #76

> I could have had a JTB that the code change had caused the emails to stop delivering, but still we wouldn’t want to say I “knew” this was the cause, because it was actually the service outage that was directly responsible. He is wrong and this is not a gettier in any way. "The code change had caused the emails to stop delivering" is not a JTB, because it is not true. Rather it was that the email server went down.

I don't think any of his code examples are really JTBs because, like you said, its not "true". In the cow example, you make an assumption based on the papier mache cow that actually turns out to be true through information you didnt have access to. All of his code examples are more about him making assumptions that turn out to be false instead based on information he didn't have access to (or rather didn't think to access at least).

I don't think this really affects the take home message from the piece, I'm just being pedantic that it doesn't parallel perfectly (which he even acknowledges people may say in the last paragraph).

Re: A three-page paper that shook philosophy, with lessons for software engineers

#83

Post by nathan_long » Tue, Jan 15, 2019, 3:04 PM UTC

serpix wrote: post #48

yesenadam wrote: post #37

Earlier quoted context omitted.

In an epistemology class once I said to the lecturer "I don't know anything." He said "Don't you know your name?"

Not good enough, point to that which knows. Where is it? Who knows it? If there is a knower to that, where is it.. Keep going with this investigation and realize there is no knower, only knowing. Eastern philosophy has nailed this thousands of years ago and we westerners are up to this day totally in the dark. We actively treat the I as a concrete object that really exists as an entity. It does not hold any closer ex…

Well, given that you don't exist, mind if I eat your sandwich?

Re: A three-page paper that shook philosophy, with lessons for software engineers

#84

Post by llagowivel » Tue, Jan 15, 2019, 3:06 PM UTC

jemfinch wrote: post #80

pwaivers wrote: post #76

> I could have had a JTB that the code change had caused the emails to stop delivering, but still we wouldn’t want to say I “knew” this was the cause, because it was actually the service outage that was directly responsible. He is wrong and this is not a gettier in any way. "The code change had caused the emails to stop delivering" is not a JTB, because it is not true. Rather it was that the email server went down.

He simply wasn't speaking with precision. If you replace "code change" with "pull request" in his statement, it's JTB.

That is correct - it is then a JTB - but not a “Gettier”. None of his examples are Gettiers.

Re: A three-page paper that shook philosophy, with lessons for software engineers

#85

Post by bunderbunder » Tue, Jan 15, 2019, 3:09 PM UTC

> A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare. But it’s still a useful idea...

At least as presented, I see the idea being used to do more harm than good.

Take the first example, with the form not autofocusing. We're already not in a Gettier case, because the author didn't have JTB. The belief that he caused the bug obviously wasn't true. But it wasn't justified, either. The fact that he had rebased before committing means that he knew that there were more changes than just what he was working on between the last known state and the one in which he observed the defect. So all he had was a belief - an unjustified, untrue belief.

I realize this may sound like an unnecessarily pedantic and harsh criticism, but I think it's actually fairly important in practice. If you frame this as a Gettier problem, you're sort of implying that there's not much you can do to avoid these sorts of snafus, because philosophy. At which point you're on a track toward the ultimate conclusion the author was implying, that you just have to rely on instinct to steer clear of these situations. If you frame it as a failure to isolate the source of the bug before trying to fix it, then there's one simple thing you can do: take a moment to find and understand the bug rather than just making assumptions and trying to debug by guess and check.

tl; dr: Never send philosophy when a forehead slap will do.

Re: A three-page paper that shook philosophy, with lessons for software engineers

#86

Post by pwaivers » Tue, Jan 15, 2019, 3:14 PM UTC

jemfinch wrote: post #80

pwaivers wrote: post #76

> I could have had a JTB that the code change had caused the emails to stop delivering, but still we wouldn’t want to say I “knew” this was the cause, because it was actually the service outage that was directly responsible. He is wrong and this is not a gettier in any way. "The code change had caused the emails to stop delivering" is not a JTB, because it is not true. Rather it was that the email server went down.

He simply wasn't speaking with precision. If you replace "code change" with "pull request" in his statement, it's JTB.

No you're talking about the first example. On the second example he says

> But—gettier!—the email service that the code relied on had itself gone down, at almost the exact same time that the change was released.

So the error was caused by the email service going down, which is completely independent of the code change/pull request.

Re: A three-page paper that shook philosophy, with lessons for software engineers

#87

Post by [deleted] » Tue, Jan 15, 2019, 3:15 PM UTC

thejohnconway wrote: post #70

phkahler wrote: post #57

>> He called them “gettiers” for short. So we used to talk about gettiers all the time, no doubt in part just because it felt clever to talk about them, but also because when you’re a programmer, you run into things that feel like Gettier cases with unusual frequency. Sometimes I think that is what philosophers are doing - feeling clever - perhaps as a defense against some negative inner problem (psychology is an out…

> Sometimes I think that is what philosophers are doing - feeling clever - perhaps as a defense against some negative inner problem (psychology is an outgrowth of philosophy after all). All science is an outgrowth of philosophy. It's very frustrating when people look the obviously trivial and sometimes silly examples that philosophers use to elucidate a problem, and take it to mean that they are interested in trivial…

[deleted]

Re: A three-page paper that shook philosophy, with lessons for software engineers

#88

Post by jeffreyrogers » Tue, Jan 15, 2019, 3:20 PM UTC

I haven't read the original paper, so maybe the example is better, but it seems the cow example fails the justified condition. The knowledge is justified if it derives from the evidence, but once we know the evidence is faulty it can no longer be used for justification by definition. It seems by extension that any justified true belief can become unjustified by the addition of new information that invalidates the justification on which the alleged knowledge is based upon.

Re: A three-page paper that shook philosophy, with lessons for software engineers

#89

Post by Retra » Tue, Jan 15, 2019, 3:20 PM UTC

chii wrote: post #44

kstenerud wrote: post #29

Earlier quoted context omitted.

Say you write some movement software. You expect that people will move forward, left, or right. You didn't expect people to try moving backward. People start moving backward, but the software happens to do the right thing due to how it was written. Is the software defective because of your missed expectation?

Yes, i would still classify the software defective. It did not reject backwards explicitly. Just because by accident it works (i.e., the consumer of the output doesn't care) doesn't mean the defect has gone away. To be not defective, the software has to explicitly reject input that it was not designed to handle. Imagine if the software updated with some changes, and the unknown input now produces an incorrect output.…

You could also argue that your expectations are defective. It is possible to accidentally solve a problem in a correct manner.

Re: A three-page paper that shook philosophy, with lessons for software engineers

#90

Post by irq-1 » Tue, Jan 15, 2019, 3:23 PM UTC

thewarrior wrote: post #15

I 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…

Denying knowledge makes your arguments work, but knowledge does exist and is a real thing. Are you sitting on a chair? The answer isn't probabilistic, you KNOW the answer. What's your name? Have you ever been to the moon?