9 ms·

> 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 i

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

burlesona 8y ago
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.”
- skywhopper 8y ago
  Right... but then how do the Gettier exceptions fit into that not-so-original insight?
  - chasedehan 8y ago
    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.
simonh 8y ago
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.
- wahern 8y ago
  What if the facsimile does all of those things? My initial reaction to the example was, "so what"? The guy _knew_ there was a cow but was wrong. The fact a _real_ cow existed behind the fascimile is irrelevant. All knowledge is contingent and relative. How could it be otherwise? What if 100% of all cow facsimiles ever displayed in the past were displayed on a farm with real cows--would that alone be sufficient to justify an inference of a cow nearby? To say that a belief is _justified_ simply begs the question--how can you _really_ know the truth of something? In the scientific method you can never prove hypotheses, you can only disprove them. 'nuff said. I find the Gettier problem entirely uninteresting myself. Someone elsethread explained it in the context of technical discourse in philosophy, in which case I could maybe appreciate the issue as a way to test and explore epistemological theories in a systematic, rigorous manner, even if for many theories it's not particularly challenging to overcome.
  - simonh 8y ago
    It's interesting because until Gettier nobody had actually proved that a justified true belief does not constitute what we commonly consider to be knowledge. It's all very well dismissing it an inconsequential, but several generations of philosophers and scientists have grown up in the post-Gettier world, before which the Justified True Belief account was widely considered to be unassailable. Yes _now_ we all know better and are brought up knowing this, but Gettier and his huge influence on later thought is the reason why and it's just that not many people are aware of this.
    - wahern 8y ago
kybernetikos 8y ago
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.
- skywhopper 8y ago
  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.
  - zrobotics 8y ago
    From the author's first example, the framing of the statement was also critical. Rebasing introduced the bug, and it would be a correct statement to say "something I just did broke autofocus." However, it would be incorrect to state "my code in the last commit broke autofocus." In many ways, programmers need to be as fussy in their statements as philosophers. Since computers are stupid, and do exactly what you specify (usually...) it is important to pay close attention to these exact details. Assuming that the new code contains the bug is incorrect, and proper debugging requires careful attention to these details. Ive certainly had bugs that were caused by some other, hidden factor like this, and typically the best way to find them is to carefully examine all your assumptions. These may be ugly questions like "is the debugger lying to me?" or "did the compiler actually create the code I intended it to make?" So while these may not be strict Gettier cases (and the author admits this in the article) they nevertheless are fairly common classes of similar problems, and framing them as such does provide a useful framework for approaching them.
20190115 8y ago
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/9780198248507.001.0001/acprof-9780198248507-chapter-11 http://www.oxfordscholarship.com/view/10.1093/acprof:oso/978... [1]: https://en.wikipedia.org/wiki/A_Causal_Theory_of_Knowing https://en.wikipedia.org/wiki/A_Causal_Theory_of_Knowing [2]: https://en.wikipedia.org/wiki/Pragmatism https://en.wikipedia.org/wiki/Pragmatism [3]: https://en.wikipedia.org/wiki/Experimental_philosophy https://en.wikipedia.org/wiki/Experimental_philosophy [4]: https://en.wikipedia.org/wiki/Experimental_philosophy#Epistemology https://en.wikipedia.org/wiki/Experimental_philosophy#Episte...
- bch 8y ago
  > 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. And to concretely tie this directly back to software[0]: Intuition is a wonderful thing. Once you have acquired knowledge and experience in an area, you start getting gut-level feelings about the right way to handle certain situations or problems, and these intuitions can save large amounts of time and effort. However, it’s easy to become overconfident and assume that your intuition is infallible, and this can lead to mistakes. One area where people frequently misuse their intuition is performance analysis. Developers often jump to conclusions about the source of a performance problem and run off to make changes without making measurements to be sure that the intuition is correct (“Of course it’s the xyz that is slow”). More often than not they are wrong, and the change ends up making the system more complicated without fixing the problem. [0] https://www.systutorials.com/3525/favorite-sayings-by-john-ousterhout-precious-experience-and-advice-for-building-systems/ https://www.systutorials.com/3525/favorite-sayings-by-john-o...
mdorazio 8y ago
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.
- bunderbunder 8y ago
  His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place. What I'm really trying to say is that the article isn't describing a situation that relates to Gettier's idea at all. Gettier was talking about situations where you can be right for the wrong reasons. The author was describing a situation where he was simply wrong.
  - darawk 8y ago
    > His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place. Yes, but the exact same point can be made about the Gettier case. The problem is inappropriately specified beliefs. The problem with that is that it's impossible ex-ante to know how to correctly specify your beliefs. For instance, you could just say that the problem with the Gettier case is that the person really just believed there was a "cow-like object" out there. Voila, problem solved! But the fact of the matter is that the person believes there is a cow - just like this person believes that their PR broke the app.
TomMckenny 8y ago
The auto complete quandary comes from ambiguity of language. The phrase "Auto-complete is broken" is ambiguous in the article encompassing at least two defintions. I know _that_ auto-complete is broken (I see it, the test fails) but I do _not_ know _why_ auto-complete is broken (some other dude did it) But I still think it's very interesting to talk about if for no other reason than that it clarifies terms and usage.
healsjnr1 8y ago
I think sometimes the spirit of these observations can be lost in the specifics. Maybe this doesn't confirm strictly to the philosophical definition, but as an analogy I find it succinct and useful. Many times I've fallen in the trap of absolutely _knowing_ in my head the reason things are the way they are, only to find out later I'm completely wrong. In most cases the evidence was right in front of me, but software is hard and complex and it is easy for even the best developers to miss the obvious. Putting a term around it, having an article like this to discuss with the team, these are all useful for reinforcing the idea that we need to continually challenge or knowledge and question assumptions.
- clairity 8y ago
  one countermeasure i use for this is to substitute the phrase "i'm pretty sure that..." in place of "i know...". that gives both you and others the mental room to consider alternative causes. the 5 why's is another more formalized technique: https://en.wikipedia.org/wiki/5_Whys https://en.wikipedia.org/wiki/5_Whys
DATACOMMANDER 8y ago
The author did have a JTB that his pull request caused the bug. The point is that we hesitate to say that he knew that his pull request caused the bug, because he had the wrong justification. If you take issue with the justification, suppose that he was supposed to be the only one working on the code that day, and that the person who introduced the bug was working from home without telling anyone. He’d then have a JTB but still lack knowledge. If even that isn’t enough justification for you, then you have a problem with the entire JTB definition, and you’re essentially offering a circular definition as an alternative (since the only justification you’ll accept is justification that itself provides knowledge).

burlesona 8y ago

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

skywhopper 8y ago
Right... but then how do the Gettier exceptions fit into that not-so-original insight?
- chasedehan 8y ago
  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.

simonh 8y ago

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.

wahern 8y ago
What if the facsimile does all of those things? My initial reaction to the example was, "so what"? The guy _knew_ there was a cow but was wrong. The fact a _real_ cow existed behind the fascimile is irrelevant. All knowledge is contingent and relative. How could it be otherwise? What if 100% of all cow facsimiles ever displayed in the past were displayed on a farm with real cows--would that alone be sufficient to justify an inference of a cow nearby? To say that a belief is _justified_ simply begs the question--how can you _really_ know the truth of something? In the scientific method you can never prove hypotheses, you can only disprove them. 'nuff said. I find the Gettier problem entirely uninteresting myself. Someone elsethread explained it in the context of technical discourse in philosophy, in which case I could maybe appreciate the issue as a way to test and explore epistemological theories in a systematic, rigorous manner, even if for many theories it's not particularly challenging to overcome.
- simonh 8y ago
  It's interesting because until Gettier nobody had actually proved that a justified true belief does not constitute what we commonly consider to be knowledge. It's all very well dismissing it an inconsequential, but several generations of philosophers and scientists have grown up in the post-Gettier world, before which the Justified True Belief account was widely considered to be unassailable. Yes _now_ we all know better and are brought up knowing this, but Gettier and his huge influence on later thought is the reason why and it's just that not many people are aware of this.
  - wahern 8y ago

kybernetikos 8y ago

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.

skywhopper 8y ago
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.
- zrobotics 8y ago
  From the author's first example, the framing of the statement was also critical. Rebasing introduced the bug, and it would be a correct statement to say "something I just did broke autofocus." However, it would be incorrect to state "my code in the last commit broke autofocus." In many ways, programmers need to be as fussy in their statements as philosophers. Since computers are stupid, and do exactly what you specify (usually...) it is important to pay close attention to these exact details. Assuming that the new code contains the bug is incorrect, and proper debugging requires careful attention to these details. Ive certainly had bugs that were caused by some other, hidden factor like this, and typically the best way to find them is to carefully examine all your assumptions. These may be ugly questions like "is the debugger lying to me?" or "did the compiler actually create the code I intended it to make?" So while these may not be strict Gettier cases (and the author admits this in the article) they nevertheless are fairly common classes of similar problems, and framing them as such does provide a useful framework for approaching them.

20190115 8y ago

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/9780198248507.001.0001/acprof-9780198248507-chapter-11 http://www.oxfordscholarship.com/view/10.1093/acprof:oso/978... [1]: https://en.wikipedia.org/wiki/A_Causal_Theory_of_Knowing https://en.wikipedia.org/wiki/A_Causal_Theory_of_Knowing [2]: https://en.wikipedia.org/wiki/Pragmatism https://en.wikipedia.org/wiki/Pragmatism [3]: https://en.wikipedia.org/wiki/Experimental_philosophy https://en.wikipedia.org/wiki/Experimental_philosophy [4]: https://en.wikipedia.org/wiki/Experimental_philosophy#Epistemology https://en.wikipedia.org/wiki/Experimental_philosophy#Episte...

bch 8y ago
> 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. And to concretely tie this directly back to software[0]: Intuition is a wonderful thing. Once you have acquired knowledge and experience in an area, you start getting gut-level feelings about the right way to handle certain situations or problems, and these intuitions can save large amounts of time and effort. However, it’s easy to become overconfident and assume that your intuition is infallible, and this can lead to mistakes. One area where people frequently misuse their intuition is performance analysis. Developers often jump to conclusions about the source of a performance problem and run off to make changes without making measurements to be sure that the intuition is correct (“Of course it’s the xyz that is slow”). More often than not they are wrong, and the change ends up making the system more complicated without fixing the problem. [0] https://www.systutorials.com/3525/favorite-sayings-by-john-ousterhout-precious-experience-and-advice-for-building-systems/ https://www.systutorials.com/3525/favorite-sayings-by-john-o...

mdorazio 8y ago

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.

bunderbunder 8y ago
His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place. What I'm really trying to say is that the article isn't describing a situation that relates to Gettier's idea at all. Gettier was talking about situations where you can be right for the wrong reasons. The author was describing a situation where he was simply wrong.
- darawk 8y ago
  > His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place. Yes, but the exact same point can be made about the Gettier case. The problem is inappropriately specified beliefs. The problem with that is that it's impossible ex-ante to know how to correctly specify your beliefs. For instance, you could just say that the problem with the Gettier case is that the person really just believed there was a "cow-like object" out there. Voila, problem solved! But the fact of the matter is that the person believes there is a cow - just like this person believes that their PR broke the app.

TomMckenny 8y ago

The auto complete quandary comes from ambiguity of language. The phrase "Auto-complete is broken" is ambiguous in the article encompassing at least two defintions. I know _that_ auto-complete is broken (I see it, the test fails) but I do _not_ know _why_ auto-complete is broken (some other dude did it) But I still think it's very interesting to talk about if for no other reason than that it clarifies terms and usage.

healsjnr1 8y ago

I think sometimes the spirit of these observations can be lost in the specifics. Maybe this doesn't confirm strictly to the philosophical definition, but as an analogy I find it succinct and useful. Many times I've fallen in the trap of absolutely _knowing_ in my head the reason things are the way they are, only to find out later I'm completely wrong. In most cases the evidence was right in front of me, but software is hard and complex and it is easy for even the best developers to miss the obvious. Putting a term around it, having an article like this to discuss with the team, these are all useful for reinforcing the idea that we need to continually challenge or knowledge and question assumptions.

clairity 8y ago
one countermeasure i use for this is to substitute the phrase "i'm pretty sure that..." in place of "i know...". that gives both you and others the mental room to consider alternative causes. the 5 why's is another more formalized technique: https://en.wikipedia.org/wiki/5_Whys https://en.wikipedia.org/wiki/5_Whys

DATACOMMANDER 8y ago

The author did have a JTB that his pull request caused the bug. The point is that we hesitate to say that he knew that his pull request caused the bug, because he had the wrong justification. If you take issue with the justification, suppose that he was supposed to be the only one working on the code that day, and that the person who introduced the bug was working from home without telling anyone. He’d then have a JTB but still lack knowledge. If even that isn’t enough justification for you, then you have a problem with the entire JTB definition, and you’re essentially offering a circular definition as an alternative (since the only justification you’ll accept is justification that itself provides knowledge).