Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jsomers.net

Post reply on HN
Print view View original

111–120 of 185 posts

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

#111

Post by n4r9 »

irq-1 wrote: post #90
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?

That's all well and good until the supposed "chair" falls apart and is revealed to be nothing but a book and some bamboo.

I see OP's comment not as denying knowledge, but rather as clarifying what is meant when people speak to each other of knowledge.

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

#112

Post by bunderbunder »

jeffreyrogers wrote: post #103
bunderbunder wrote: post #94

Earlier quoted context omitted.

What you're saying is more or less exactly what the paper was getting at. It's hard to say based on a short Internet comment, but it sounds like the spot where your disagreement comes from is that you're understanding the word "justified" in a slightly different way from how epistemologists were using it. For example, one of the responses to Gettier's paper was to suggest that maybe the definition of "justified" shou…

Thanks, I think you're right about how I was understanding the word "justified". I like bringing up philosophical disagreements on HN since it often gets responses like yours :)

Yeah, sorry, though, I realized after I posted that I failed to properly acknowledge that you hit the nail on the head -- I picked that response to Gettier specifically because it matched your criticism.

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

#113

Post by perfmode »

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

Where do you fall on autonomous cars? It’s okay to be anti. I’m just curious

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

#114

Post by simonh »

bunderbunder wrote: post #85

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

Arguably the Gettier example of the cow falls into the same realm. Cows move, eat grass and go 'Moo. Did the observer see it do these things, or just go on the silhouette? Then they were not rigorous enough to have a justified belief.

But then we can get back to a better Gettier case if we suppose that Boston Dynamics happens to be testing their new Robo-Cow military infiltration unit in the field at the time.

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

#115

Post by kybernetikos »

bunderbunder wrote: post #85

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

I agree with your point I think, however all of the Gettier cases that I know of seem to be examples of a particular choosing of the fact. In the cow example, he had a justified true belief that there was a cow in the field, but if you had phrased it more naturally as 'I know that that black and white shape I see in that field is a cow', that would not have been true.

I suppose the point is just that having a justified true belief purely by chance, almost certainly depends on the justification itself being a false belief, even in true Gettier cases.

Anyway, I find the whole thing fairly unmysterious - I just take 'know' to be a particularly emphatic form of 'believe', and I like your conclusion.

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

#116

Post by skywhopper »

burlesona wrote: post #104
bunderbunder wrote: post #85

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

You make a good point, but I think the framing of “justified true belief” may still be useful for the reason you illustrated. It gives a developer a nice way to sanity check their instinct. Instead of “I’m sure my code broke this,” asking “is this belief justified” may help them pause and consider “well I did rebase so I can’t really be sure, I need to eliminate what’s in the diff first.”

Right... but then how do the Gettier exceptions fit into that not-so-original insight?

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

#117

Post by skywhopper »

kybernetikos wrote: post #115
bunderbunder wrote: post #85

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

I agree with your point I think, however all of the Gettier cases that I know of seem to be examples of a particular choosing of the fact. In the cow example, he had a justified true belief that there was a cow in the field, but if you had phrased it more naturally as 'I know that that black and white shape I see in that field is a cow', that would not have been true. I suppose the point is just that having a justifi…

Yes, this was my gut reaction to the Gettier exceptions as well. But you picked out the specific detail that seems to clinch it for me: the framing of the "fact" under question matters greatly.

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

#118

Post by 20190115 »

bunderbunder wrote: post #85

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

Philosophy major here. Didn't read the article, but will point out:

The significance of Gettier problems as we investigated it is the exposure of an entirely _wrong_ mode of philosophy: philosophizing by intuition. Ultimately, the reason Gettier problems are significant is because for philosophers, the textbook Gettier problem works because _for philosophers_ the problem captures their intuitions of knowledge, and then proves the case of knowledge fails.

Most normal people (i.e., not philosophers) do not have the same intuitions.

After Gettier analytical philosophers spent decades trying to construct a definition for knowledge that revolved around capturing their intuitions for it. Two examples are [The Coherence Theory of Knowledge][0] and [The Causal Theory of Knowldege][1]. Ultimately nearly all of them were susceptible to Gettier-like problems. The process could be likened (probably) to Goedel's Incompleteness proof. They could not construct a complete definition of knowledge for which there did not exist a gettier-like problem.

Eventually, more [Pragmatic][2] and [Experimental][3] philosophers decided to call the Analytical philosophers bluff: [they investigated if the typical philosopher's intuition about knowledge holds true across cultures][4]. The answer turned out to be: most certainly not.

More pragmatic epistemology cashes out the implicit intuition and just asks: what is knowledge to us, how useful is the idea, etc. etc. There's also a whole field studying folk epistemology now.

[0]: http://www.oxfordscholarship.com/view/10.1093/acprof:oso/978...

[1]: https://en.wikipedia.org/wiki/A_Causal_Theory_of_Knowing

[2]: https://en.wikipedia.org/wiki/Pragmatism

[3]: https://en.wikipedia.org/wiki/Experimental_philosophy

[4]: https://en.wikipedia.org/wiki/Experimental_philosophy#Episte...

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

#119

Post by mdorazio »

bunderbunder wrote: post #85

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

How is it not a JTB?

Belief: The pull request broke the search field auto focus.

Truth: The pull request did break it. There was an additional reason beyond the pull request unknown to the author, but that's not important to the Truth portion here.

Justified: This is the only one you can really debate on, just as philosophers have for a long time. Was he justified in his belief that he broke autofocus? I think so based on the original JTB definition since there is clear evidence that the pull request directly led to the break rather than some other event.

I think that when claiming it's not a JTB you're choosing to focus on the underlying (hidden) issue(s) rather than what the author was focusing on, which is kind of the whole point of Gettier's original cases. For example Case I's whole point is that facts unknown to Smith invalidate his JTB. In this programming example, facts unknown to the author (that someone else introduced a bug in their framework update) invalidate his JTB as well.

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

#120

Post by chasedehan »

skywhopper wrote: post #116
burlesona wrote: post #104

Earlier quoted context omitted.

You make a good point, but I think the framing of “justified true belief” may still be useful for the reason you illustrated. It gives a developer a nice way to sanity check their instinct. Instead of “I’m sure my code broke this,” asking “is this belief justified” may help them pause and consider “well I did rebase so I can’t really be sure, I need to eliminate what’s in the diff first.”

Right... but then how do the Gettier exceptions fit into that not-so-original insight?

Example would be the above comment about "There is a cow in that field". It would be to then ask, did I see the cow move, eat, or do anything else that you would expect a cow to do - rather than just seeing the silhouette?

I generally think the point is that you oftentimes have beliefs about why something broke and that it is important to check your beliefs.

Post reply on HN