12 ms·

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

566 points by jsomers 8y ago

austinjp 8y ago
The "cow in the field" example reminds me of two heuristics I like: am I right for the wrong reason?; am I wrong for the right reason? Being right for the wrong reason is dangerous: it's not easy to spot, and it perpetuates false sense of security leaving "black swan events" unanticipated. This might occur during debugging as the article points out, or e.g. during A/B testing of a product. Bring wrong for the right reason is just plain frustrating.
- chii 8y ago
  > Bring wrong for the right reason is just plain frustrating. what's an example of being wrong for the right reason? I can't think of any cases where this happens...
  - reinhardt1053 8y ago
    In the context of political forecasting, imagine that you are a defence chief who is faced with an unquantifiable external threat, as the US was by Russia during the Cold War. You can predict that this enemy is a very great threat, or you can say that it isn’t much of a threat, but the outcomes are asymmetric. If you say that the threat is a grave one, and strengthen your defences accordingly, then if the enemy attacks, you were clearly right to take the threat seriously. If the enemy doesn’t attack, you were still right, because you can say that the enemy only didn’t attack because of the action you took. On the other hand, if you dismiss the threat as insignificant, and the enemy attacks, then at best your career comes to a sudden and unpleasant end. So therefore, it is always right to over-emphasise the threats, and if you turn out to be wrong, you were wrong for the right reason.[1] [1] https://wiseinvestment.co.uk/news/antiques-roadshow-tony-yarrow-november-2014 https://wiseinvestment.co.uk/news/antiques-roadshow-tony-yar...
    - chii 8y ago
      > always right to over-emphasise the threats, and if you turn out to be wrong, you were wrong for the right reason. if the audience is not receptive to the concept of opportunity cost, then yes. Unfortunately, a majority of people over-estimate the need for security and thus, allow themselves to be fooled into believing that this over-emphasis, no matter the cost, is justified. Just look at the TSA!
  - lmm 8y ago
    Nate Silver is widely seen as having forecast the election "wrong" because he said Trump had a 20% chance of winning. AIUI his position is that his model was right and 20% was an accurate probability.
    - hopler 8y ago
      The essence of probability is being wrong for the right reasons (less often * weight then being right for those same reasons).
  - zacherates 8y ago
    Games are a place this comes of frequently. In poker you will often make the "right" (highest EV) play and still lose a given hand. Making the highest odds plays (and being able to figure out what they are) over and over again regardless of how the individual hands turn out is how you win. Obviously, you can also win while making the wrong plays by getting lucky (right for the wrong reasons). Evaluating your play based on the outcome of the hands (did you win or lose) rather than the plays you made with the information you had at the time is called Results Oriented Thinking: https://www.pokerdictionary.net/glossary/results-oriented-thinking/ https://www.pokerdictionary.net/glossary/results-oriented-th... ... and it is a pernicious mistake (with wider applications than just poker :).
  - andrewf 8y ago
    My compensation includes company stock. I sell that stock, and some of the proceeds end up in index funds. I do this because I want a diversified portfolio. My employer's stock is up 28% over the last year, S&P 500 is down 6%. I guess my goal going in was to reduce variance, so I wasn't "wrong" about anything. 36% more money would be nice, though. (I haven't changed my strategy as a result)
newsbinator 8y ago
These cases seem to come up often (weekly?) in software development. I wonder how often they come up in other professions. One common case is when you change or delete a comment, and suddenly something breaks. It couldn't have been the comment... but it was working fine before my edit... wasn't it?
- veddox 8y ago
  Considering the fact that so much of programming is error finding, it's useful (and probably necessary) to have a solid heuristic for quickly determining causal relationships.
- C1sc0cat 8y ago
  I have had bugs that where fixed by recompiling the entire application
- the6threplicant 8y ago
  Or the bugs that disappear when you're debugging and then come back hen you're not.
  - hobofan 8y ago
    Also known as Heisenbug[0]. [0]: https://en.m.wikipedia.org/wiki/Heisenbug https://en.m.wikipedia.org/wiki/Heisenbug
- chrismorgan 8y ago
  And then as you look closer, you wonder how it ever worked. Hang on, did it ever work?
  - Insanity 8y ago
    I lost quite a few hours trying to restore a feature after I made a commit, only to find out that it was broken for weeks already. Or worse, was not even implemented yet. It's amazing how that just keeps on happening.
- 8y ago
p2detar 8y ago
This hits close to me as a possible reason why I could never get good at solving geometry problems, solid geometry especially. Most problems would be trivial when one assumes specific preconditions, but my mind was always wandering around, looking at all potential sides of a problem and I could never solve anything. To quote the author from my particular pov: a problem has multiple potential causes, and you have every reason to believe in one of them, even though another is secretly responsible. Reminds me that I need to pick up a book and re-learn the damn thing. It really saddens me that I suck at geometry.
- azmodeus 8y ago
  I think you should try looking at geometry more like a creation initially then a problem. In this manner you can see assumptions as just building up more simple worlds with those constraints. I have found this view helps when teaching geometry as it empowers the mind.
- gdy 8y ago
  This is surprising. Russian geometry problems, as I remember them, required creative thinking, which seem to be exactly the opposite to what you are describing.
veddox 8y ago
I had a philosophy lecture last year that included a lot of epistemology (Theory of Knowledge). We talked a fair bit about justified true beliefs, but Gettier only came up in a side note - the professor being more interested in skepticism and the responses thereto. Never would have dreamt of applying that lecture to programming, though.
stareatgoats 8y ago
The 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 based on facts, when in all probability they are merely beliefs fraught with assumptions. Some people might be good at being skeptics in all areas, but I sense most share my own ineptitude here, the reason probably being that any such (incorrect) beliefs don't immediately come back and bite us, as in programming.
- james_s_tayler 8y ago
  The funny thing about development is what's say 90% of the time you are convinced everything is correct and should be working and it's immensely frustrating because it's not, so you know you are wrong but are unable to offer yourself a more convincing theory and just get stuck until something clicks. But then there's that 10% of the time where you're actually right. And you don't know which one it's going to be. So you have to calm yourself down like "I know I think Im right about this but clearly Im not" but at the same time you have to hold onto that conviction because you're right damnit. Haha.
  - hopler 8y ago
    As Raymond Smullyan proved, everyone is either inconsistent or conceited.
    - james_s_tayler 8y ago
      http://www.mit.edu/people/dpolicar/writing/prose/text/epistemologicalNightmare.html http://www.mit.edu/people/dpolicar/writing/prose/text/episte... Reading this made my day.
- croo 8y ago
  Hard to translate to other domains without a tool to prove you wrong until you are right.
austincheney 8y ago
This 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 input (serendipity) * unexpected output from an unknown input (unintentional) For example I maintain a parser and beautifier for many different languages and many different grammars of those languages. In some cases these languages are really multiple languages (or grammars) imposed upon each other and so the application code must recursively switch to different parsing schemes in the middle of the given input. The more decisions you make in your application code the more complex it becomes and predicting complexity is hard. Since you cannot know of every combination of decisions necessary for every combination of input you do your best to impose super-isolation of tiny internal algorithms. This means you attempt to isolate decision criteria into separated atomic units and those separated atomic units must impose their decision criteria without regard for the various other atomic decision units. Provided well reasoned data structures this is less challenging than it sounds. The goal in all of this is to eliminate unintentional results (see forth bullet point above). It is okay to be wrong, as wrong is a subjective quality, provided each of the atomic decision units are each operating correctly. When that is not enough you add further logic to reduce the interference of the various decision units upon each other. In the case of various external factors imposing interference you must ensure your application is isolated and testable apart from those external factors so that when such defects arise you can eliminate as much known criteria as rapidly as possible. You will never be sure your open-ended system works as intended 100% of the time, but with enough test samples you can build confidence against a variety of unknown combinations.
- chii 8y ago
  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.
  - 8y ago
osharav 8y ago
Interesting to compare this with a simpler term - "Red herring" as something that throws you off course.
mindwork 8y ago
I learned this word, but I'm scared and wondered by it every time. I think it fits here. There is two worlds: believed and true. And when they merge it's called "peripeteia"
- Rzor 8y ago
  I read the Wikipedia's entry. It seems that it could be better explained as a "plot twist": when your confidence in an outcome is overturned, for better or worse.
- kensai 8y ago
  Peripeteia in modern Greek means simply "adventure".
thewarrior 8y ago
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 the cause. However he could have increased the probability by going back over commits and confirming that his exact commit introduced the bug. Now the probability goes even higher. But it could still be machine specific a cosmic ray or whatever but the odds are over whelmingly low. In practice causal reasoning also works in a probabilistic fashion. I have a simple model saying that if a planes engine is on then it’s flying. Its a single step probability and so it’s not very accurate in the real world. I do a bunch of experiments and say a plane is flying if the engine is on and air is going over it’s wings faster than a certain speed. Now we have two correlations connected by a causal model that works in many other cases. Hence the probability of it being correct rises. But at the same time we should never mistake direct correlation for causality. But in daily life it’s “good enough”.
- TuringTest 8y ago
  I like the term "probabilistic survival engine". It explains a lot of phenomena in social trends, religion, politics, and even the practice of science.
  - elijahbear 8y ago
    The first time I heard to a brain referred to in this way it was in the scifi book Blindsight by Peter Watts. The book is pretty solid and deals with a lot interesting ideas from cognitive science.
- sevensor 8y ago
  I'm sad that I had to read so far down the thread to find this comment, which beautifully cuts right through the argument. The problem is the idea of absolute knowledge -- knowledge is probabilistic and contextual. If I'm driving by the field in a car, I may be duped by the cow, but my perception that I'm surrounded by pasture land is more than adequate to support the activity of driving. If on the other hand, I'm Farmer Jones and I'm searching my pasture for Susie the cow, well, I'm not going to be taken in by a statue of a cow for more than a split second anyway.
amelius 8y ago
As software abstractions often put up facades in front of similar abstractions, this is bound to happen to us software developers.
bloak 8y ago
To 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.
- hobofan 8y ago
  Sure, that is widely useful. You can apply that to the real world if you then add social processes and see "knowledge" or "truth" as shared belief between a chosen set of people (or all of humanity). Then you can go down the whole rabbit hole of beliefe aggregation and voting theory.
- yesenadam 8y ago
  In an epistemology class once I said to the lecturer "I don't know anything." He said "Don't you know your name?"
  - bloak 8y ago
    Isn't that connaître rather than savoir? So much philosophy is playing with words.
  - serpix 8y ago
    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 examination and evaporates entirely the closer it is questioned.
    - mbrock 8y ago
      I know my name just like I make a cup of tea. It's not you who makes my cup of tea, right, so who is it? Well, me—the referent of my name, this person right here. That's just part of how our language works. It doesn't seem to matter whether I am a "concrete object" or some swirly pattern of becoming or indeed even an illusion! The English word "I" does not refer to an eternal soul or "atman." If you stare long enough at an ice cream you'll have the marvelous insight that in reality there is no concrete ice cream entity, not least because it melts. Yet people don't go around saying "wake up, there are no ice creams!" Why is that?
coldtea 8y ago
>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...
- chii 8y ago
  In science, experiments with a good control is how this problem is removed. And repetition is how to control for coincidences and outlier measurements. Software engineering has many of these Gettier cases, because most software engineers do not follow the scientific method when investigating a problem!
- yesenadam 8y ago
  Well, why not write them down for us?!
  - coldtea 8y ago
    As if they're difficult to derive on one's own? You believe X has cancer because he has the symptoms and you can see an offending black spot on their X-ray. The lab results say the black spot was just a cyst but X indeed has cancer in the same organ.
    - gjm11 8y ago
      That sounds to me like (1) not a clear example of a Gettier case and (2) something that would, in fact, be rare. #1 because one of the reasons for your believing X has cancer is that "he has the symptoms", which (if I'm understanding your example correctly) is in fact a consequence of the cancer he actually has; so, at least to some extent, your belief is causally connected to the true thing you believe in just the way it's not meant to be in a Gettier case. #2 because (so far as I know) it's not at all common to have both (a) cancer in an organ that doesn't show up in your X-ray (or MRI or whatever) and (b) a cyst in the same organ that looks just like cancer in the X-ray/MRI/whatever. I'm not a doctor, but my guess is that this is very unusual indeed. So this isn't a very convincing example of how clear-cut Gettier cases aren't rare: it's neither a clear-cut Gettier case nor something that happens at all often.
deleted 8y ago
[deleted]
Antonio123123 8y ago
This 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.
bryanrasmussen 8y ago
I 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.
pjc50 8y ago
There'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.
- daveFNbuck 8y ago
  If the real cow (B) was not present, your belief that there was a cow in the field would be justified but not true. Seeing a the fake cow (A) justifies your belief that there's a cow in the field. Adding a real cow (B) that you can't see doesn't remove the justification.
  - pjc50 8y ago
    Good point, I've edited "justified" to the full phrase "justified true belief"
    - daveFNbuck 8y ago
      If the belief is both justified and true, how is it not a justified true belief?
RootKitBeerCat 8y ago
So just more simply “red herring”
nga_ 8y ago
Is not this same as coincidence?
mlthoughts2018 8y ago
I actually disagree with the Gettier thought experiment and don’t believe it demonstrates anything interesting. When you see the cow (but it’s really a convincing model), then in your mind, there should be some probability assigned to a variety of outcomes. The main one would be a cow, another one might be that you’re hallucinating, and so on down the list, and somewhere the outcome of cow-like model would be there. From that point you can go in at least two directions, one would be something like a Turing test of the fake cow... beyond a certain point it’s a matter of semantics as to whether it’s a real cow or not, or you could say that your “justified true belief” had to apply to the total state of the field. If you believed there was both a cow model and a cow behind it, that woukd be justified, but the existence of the cow behind the model would not justify incorrect belief that the model was a real cow, in the sense of not admitting uncertainty over the things you see.
- ordu 8y ago
  Your model of thinking is something like idealized bayesian one, not like human. If your mind decided that something is true with sufficient probability, it then fails to see alternative explanations. This "something" will be a reality to you, not just a belief about reality. But it is not the all. Your mind have some ideas associated with cow you've seen, and those ideas also becomes beliefs of yours. Implicit beliefs, you are probably not aware of them, you could notice this implicit beliefs only if they will begin to contradict evidence in a sharp way. For example, you can implicitly decide that this is a soft tempered cow, that would like to lick you in a face, if you come near. It was not important when you saw the model of a cow, so you didn't become consiously aware of your idea of a cow temper. But it was planted in you idea of reality. Maybe you would have an intention to come near the cow to be licked in the face, and you might be unaware of this intention. Human mind can easily manage such tricks. And it leads to a funny thing. You saw the model of a cow, and it make you believe that there is a cow in the field and that you saw a cow. Then you could find a heap of poo, and you will strengten your beliefs futher. You might find a lot of evidence and it all will be explained under assumption that you saw a cow. And this evidence will strenghten your belief that you will be licked in the face, when you come near the cow. But you didn't saw the cow that made this heap of poo. The real cow is pitch black, with a horns of gigantic size and they are really sharp. The real cow has red glowing eyes and it is going to kill you. But before you see the real cow itself, all the evidence that would point that there is a cow would also reinforce the idea of soft tempered black and white cow. The longer you manage to keep youself oblivious to real cow traits, the more surprised you will become when you find the real cow.
callesgg 8y ago
My own opinion is that knowledge is always relative to a perspective. It is only valid in a context. Nothing is absolute. Example: 1=1 is something i know is true cause i know the rules of mathematics. There is no absolute truth to that.
- gerbilly 8y ago
  10+3 = 13 when talking about coconuts, but 10+3 = 1 when talking about time[1] [1] In America anyways.
golergka 8y ago
The first example is exactly the reason why I hate rebases and prefer merges and complicated history instead. It may be more complicated, but it doesn't swipe problems under the rug.
- hopler 8y ago
  That's why in some quarters it's called git debase.
phkahler 8y ago
>> 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 outgrowth of philosophy after all). The whole cow story stinks of telling someone "you're right, but you're also WRONG! Your perception of reality is BROKEN!". To me knowledge is simply having a model of the world that can be used to make useful predictions and communicate (and some other things). Aside from that, it doesn't matter if your model is "grounded in reality" until it fails to work for you, at which time it can be helpful to realize your knowledge (model) needs adjustment. One way to resolving the authors first software issue would be to check a diff between what he committed and the previous production revision - this would quickly uncover the changes he "didn't make". This is an old lesson for me - what I changed may not be limited to what I think I changed. It's a lesson in "trust but verify". There are any number of ways to view it, but in the end we only care about ways that lead to desired outcomes weather they're "right" or not. On a related note, I've found that software is one of the only places where there is a "ground truth" that can be examined and understood in every detail. It's completely deterministic (given a set of common assumptions). I've found the real world - and people in particular - to not be like that at all.
- ozy 8y ago
  Exactly, one ontology of knowledge is: pointers (names), categories (matchers/recognizers), models (descriptions of systems). The first two have all the problems philosophers talk about. But the last one does not. Not even underdeterminism, unless the system of the model is fundamental or fades into history or is a "wicked" problem.
- thejohnconway 8y ago
  > 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 and silly things. Being right for the wrong reasons is a common and difficult problem, and some if the solutions to it a really insightful and powerful ideas. > Aside from that, it doesn't matter if your model is "grounded in reality" until it fails to work for you, at which time it can be helpful to realize your knowledge (model) needs adjustment. It might matter a great deal if your model is not grounded in reality - there are situations where that can kill you. It also seems like one of the fundamental aims of science, to have theories fail less often.
ozy 8y ago
Note most gettier cases are plays on our intuitions: What feels like a pointer is actually a category. That is, it feels like it points to one, but it points to many. Like both examples given here: https://en.wikipedia.org/wiki/Gettier_problem https://en.wikipedia.org/wiki/Gettier_problem .
- hopler 8y ago
  For the C heads, you mean what feels like a pointer is actually an array? :-)
dm03514 8y ago
I can imagine a future where what's true generally describes itself (like terraform on drugs for software :p) Imagine software that is fully self descriptive and would no longer require engineers to individually interpret what's happening because the software would tell us. The system would be a graph of every single component and all possible connections between them, and all variants of each component and state that it could be in. When we introduce a change we would be aware with perfect information about the affect to the states and the paths between them. In the example the Mental Model was at a level too shallow, it should have only affected the paths between the autofocus and the user. But the bug necessitated a larger mental model (the author was considering too small subsection of the graph). I'd hope in the future we could reach a state where the program could have detected that the frame refactor would have an affect on the autofocus and all other components instead of being an implementation detail.
scyclow 8y ago
This reminds me of a recent event at WrestleKingdom 13, a Japanese professional wrestling event where, as you might imagine, pretty much everything is planned and choreographed ahead of time. In the opening match, Kota Ibushi suffered a concussion. Some doctors came out, carried him out on a stretcher, and took him to the back. As it turns out, this was all planned. The doctors were fake, and this course of events was determined ahead of time. But coincidentally, Ibushi _actually_ suffered a real-life concussion in the match. Wrestling always has an interesting relationship with reality.
chasingthewind 8y ago
Another really great work that's related to some of these concepts is "Naming and Necessity" by the philosopher Saul Kripke. https://en.wikipedia.org/wiki/Naming_and_Necessity https://en.wikipedia.org/wiki/Naming_and_Necessity It investigates how we assign names to things and what those names mean and how we can reason about them.
pwaivers 8y ago
> 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.
- jemfinch 8y ago
  He simply wasn't speaking with precision. If you replace "code change" with "pull request" in his statement, it's JTB.
  - llagowivel 8y ago
    That is correct - it is then a JTB - but not a “Gettier”. None of his examples are Gettiers.
  - pwaivers 8y ago
    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.
- el_cujo 8y ago
  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).
bunderbunder 8y ago
> 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.
jeffreyrogers 8y ago
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.
- bunderbunder 8y ago
  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" should be altered to include a provision that invalidating the justification would imply that the belief is false. So, for example, under that modified definition, the visual evidence couldn't serve as a justification of the belief that there is a cow in the field, because it allows the possibility that it isn't a cow but there still is one in the field. On the other hand, it would work for justifying a belief like, "I can see a cow from here." (Yeah, there's another cow in the field, but it's not the one you think you see.) But, still, that wasn't quite the definition that the mid-century epistemologists who made up Gettier's audience were using. (ETA: Also, the original paper didn't involve cattle at all. Wikipedia has what looks like a good summary: https://en.wikipedia.org/wiki/Gettier_problem#Gettier's_two_original_counterexamples https://en.wikipedia.org/wiki/Gettier_problem#Gettier's_two_...)
  - jeffreyrogers 8y ago
    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 :)
    - bunderbunder 8y ago
paulsutter 8y ago
“Justified true belief”? All our knowledge is subjective by definition. We don’t even know whether we’re living in a simulation. Personally I doubt that we’re living in a simulation. But the fact that we could be, demonstrates that we don’t have objective knowledge. No cows needed in the field explain it Philosophy might better be called “the history of flawed thinking”
- scotty79 8y ago
  Also specific example with a cow is silly. Belief there is a cow in the field is not really justified. It just seems justified to the observer that can't tell difference between model and a real cow.
  - deleted 8y ago
    [deleted]
- lamacase 8y ago
  By what definition? The "notion" of "justified true belief" WAS the definition of knowledge prior to these complications. Just saying "everything is subjective" is more tedious than making meaningful distinctions, in my subjective opinion
  - whytaka 8y ago
    I think GP means that the justification of JTB by definition is recursive and thus has no real foundation. To call something 'true' is to know it is 'true'. If we are bothering to debate whether knowledge is possible, JTB is unconvincing.
- gnode 8y ago
  > We don’t even know whether we’re living in a simulation. I think it's actually worse than this. This scenario suggests that our minds are capable of infallible reasoning yet we may not be able to trust our observations. Really, I don't think we can even trust our own mind, and therefore JTB is undefinable.
voidpointer 8y ago
Somehow, the examples all sound more like a quality and/or testing issue. The workflow seems prone to people rebasing to a buggy state and at that point, in a non-trivial system, all bets are basically off. Basically I need to be able to have a "JTB" about a pull request having undergone enough review and testing before being merged on the master that it doesn't introduce such glaring regressions as cited in the examples. If that cannot be ensured, I'm setting myself up for one goose chase after the other...
rdlecler1 8y ago
Isn’t this just a confounding factor?
azinman2 8y ago
Sounds like (from the cases presented) an over intellectualisation of “coincidences.”
perlgeek 8y ago
> (Yes, I should have caught the bug in testing, and in fact I did notice some odd behavior. But making software is hard!) How often have I noticed some "odd behavior" in testing, and later wasn't able to reproduce it? Some nagging feeling that I broke something remained, but since I've deployed a new version (that fixed something else), and I couldn't reproduce the "odd behavior", I tricked myself into ignoring it. And then I deployed to production, and shit hit the fan. Now I try to pay more attention to those small, nagging feelings of doubt, but it takes conscious effort.
anthonyriggi 8y ago
I don't like this approach. If everyone were to approach a problem with this mentality it would conjure doubt in the entire process. Nothing would ever get done. Question: "how do we know if anything exists?" <--(an extreme example). Answer: "well we don't but it doesn't help us with the realities of the problem at hand." I think this idea introduces confusion and does more harm than good, in my opinion.
gorpomon 8y ago
It's a bit in the weeds, but I think the author has a wrong JTB. They author deployed multiple changes, and just incorrectly assumed that their PR was the one that introduced the bug. They author had incorrect knowledge about what was being deployed. If something in their deploy process indicated that in fact only their code was being deployed then perhaps it's a JTB? But otherwise I think it's just a bit off. However, the gist of it is correct. We often update dependencies or deploy more than we think we do. We have an "us" focused view of our code, and keeping gettier cases in mind helps us break out of that. Just recently I kept thinking that I didn't know how to write a jest test, when in fact I was using a version of Jest which didn't support a certain method. It's easy to think it's our fault, when in fact there can be deeper reasons.
agarden 8y ago
I don't see any of his examples as Gettier cases. He thought his code caused the autofocus problem; it didn't. He thought someone else's push had broken email, but instead the service happened to go down at the same time. A proper Gettier case would be when you write code that you believe to be correct and it does work, but not for the reasons you think it does. Often this eventually bites when some edge case arises. I run into this fairly often playing chess. I calculate out some tactic, decide it works, and play the first move. But my opponent has a move I overlooked which refutes the line I was intending to play. Then I find a move that refutes his, and the tactic ends up working in the end anyway, just not for the reasons I thought it would.
- theoh 8y ago
  Here's an example that comes to mind: A programmer writing a function refers to a local variable, "status", but thinks they are referring to a global variable. The code works by chance because the variables happen to have the same (fixed) value. The variable shadowing means that the programmer could quite plausibly be confused and believe that they were accessing the global variable ("justification"). "I know I checked the status variable, like I was supposed to".
ppeetteerr 8y ago
This reminds me of how some studies are proven to be true but the reason they are true are not the reasons the author of the study presents. Instead, the true-ness is either a coincidence or a correlation, not causation. These people go on to write books and entire industries are formed around these hypothetical truths and it takes years to undo the damage of the original study (e.g. marshmallow test, jam experiment)
robbrit 8y ago
This is precisely why when dealing with bugs I advise juniors to avoid asking the question, "what changed?" Gettier cases are just one problem that you can face when asking that question. Instead I usually tell them to do it the proper way: start from the bug, and work backwards to understand why that bug is happening. At that point the change that caused the bug becomes obvious, and most of the time we realize that we probably wouldn't have come to that conclusion by looking just at what changed.
- RugnirViking 8y ago
  This is one of two approaches to the problem of debugging a system. It's advantage is that assuming the programmer can focus on everything they have seen in the debugger for long enough, they can find where the issue arises. It's disadvantage is that as systems get larger, it can get exponentially more time consuming. As programmers we sometimes learn tricks (read: assumptions) to cut down this time, but in the end, the complexity of the system beats all but the very best/most determined. Consider tracing a bug in this manner through the entire code of something as complicated as an operating system. Most of the code you did not write yourself, and you have likely never seen before and no idea what it does. Each new frame the debugger reaches you have to spend time understanding what is happening before determining if this is where the problem occurs, and there are so many frames that it can become difficult to sort through them all.
scottlamb 8y ago
As usual, science has a more practical take on this. Occam's Razor says that if you see a cow shape and hear a cow sound coming from that direction, the most likely explanation is that you're seeing a cow. It retains the possibility this isn't true; the belief can be falsified in several ways: by examining the cow more closely, by the real cow walking out from being the fake one, etc. I think it follows that we never absolutely "know" something. We asymptotically approach knowledge. The scientific method is a way of approaching truth.
gweinberg 8y ago
I don't understand how anyone could have ever thought "justified true belief" was a good definition of knowledge, since the question of "what constitutes justified belief?" is muddier than the question "what constitutes knowledge?" in the first place. Further, even without considering such absurd situations as a real cow hiding behind a fake cow, if you see something that, based on its appearance, almost certainly is a cow, the near certainty doesn't change into absolute certainty just because what appears to be a cow is in fact a cow.
oh_sigh 8y ago
I was surprised when I first learned that this was a novel philosophical concept, because I recall reading a Renaissance-age Italian story(maybe from the De Cameron?) that talks about this: Basically, a man sees his wife walking in the town square with the hat of a friend of theirs, and this leads him to believe that she is cheating with that friend. It turns out that he just offered the hat to her in the market, to help her carry some eggs home, and she was going to return it. So, she goes and returns it, the husband follows her, and it turns out she actually is cheating on the husband with the friend, but the hat hat nothing to do with it.
aaroninsf 8y ago
Always bemused and not a little confused that anyone (most notably, Americans) still spend so much time and energy on analytical philosophy [and its Quine-y assertions about semantics] so many decades after its sort of formal semantics collapsed as a useful way of analyzing natural language. Linguistics (not to mention, comp lit or continental philosophy) departments have an order of magnitude more to say about meaning in natural language and have had for... decades and decades. I just don't get it.
mcgwiz 8y ago
I initially thought this article might be about programming by coincidence [1] or maybe about user experience superstitions [2], but after reading it I wonder if this isn't just about the practice of debugging. Software is complex. When someone begins investigation into a bug, if the fix is not immediately found, it becomes a matter of running down a list of hypothetical causes. As one's experience deepens, both the "running down" and the curating of the "list" become more efficient. IMHO this article is merely about a developer who was unaware of certain hypothetical causes. 1: https://pragprog.com/the-pragmatic-programmer/extracts/coincidence https://pragprog.com/the-pragmatic-programmer/extracts/coinc... 2: https://www.nngroup.com/articles/quality-assurance-ux/ https://www.nngroup.com/articles/quality-assurance-ux/
joe_the_user 8y ago
I know mathematical logic but I don't know much about conventional philosophy. The Gettier argument seems to indicate that a system of false propositions used to arrive at a conclusion could be called "justification" in normal epistemology - that seems a bit disturbing. Being "justified" in believing X means just having some reason, maybe utterly bogus but existing and convincing to you, for believing X (and then X becomes knowledge even if X happens to be true entirely different reasons). How could no one have commented previously if that was how the system was? Edit: the main practical implication of the argument seems to be that one cannot assume that when you have argument for X and when you then you get empirical evidence for X, you cannot take that a proof your argument for X is true. It might be suggestive of the truth of the argument but the structure of the argument also has to be taken into account. But that's been a given scientific and statistical investigations for a long time.
isacikgoz 8y ago
The article was great. I also find philosophy and software correlates occasionally. The response of the author to the gettier cases are expected behavior. In fact it is a blessing. 99% of the time there is a cow, we experienced that before and that’s the reason of our confidence. We easily solve our problems with this approach.
jungler 8y ago
Although many folks have raised the "not Gettier" objection, I would propose that the premise of applying the test to debugging is wrong. Debugging means that your assumptions were already faulty: otherwise the system would not have bugs. That is, the act of programming means working on an unfinished thought, something that can reflect some beliefs but compromises on being an exactly true expression of them. And so the weight of philosophical reasoning should appear at design time. What occurs after that is a discovery phase in which you learn all the ways in which your reasoning was fallacious - both bugs and feature decisions.
karmakaze 8y ago
So just to be clear, a 'gettier' is when something you Believe and have Justification for turns out to be false? Actually True J B 1 1 knowing 1 0 denying 0 1 lucky hunch 0 0 sceptic, default position Actually False J B 1 1 mis-justification: un/incorrectly-verified 1 0 lucky denial of mis-justified 0 1 superstition 0 0 sceptic, default position
- hopler 8y ago
  No, it's when you get the right answer for the wrong reason, like a math problem solution that has two mistakes that cancel out in the end result, but are still incorrect logic
sunstone 8y ago
Didn't Descartes cover this with "I think therefore I am."? Everything else is varying degrees of speculation.
pitermarx 8y ago
It might be true that even though I have a JTB about something I might be wrong. Nevertheless, I think It would be resonable to act upon a JTB as it it was true. For all effects it is true to the best of my knowledge. This does not mean I shun down new information that might make me to change my JTB. And if having a JTB is not knowledge, what is? What can we know? We can always imagine a world where even our most firm JTB might be false. If a JTB is not a good case to use the word knowledge I don't know what is
thefringthing 8y ago
My reaction Gettier cases as a philosophy minor was that J is the only philosophically interesting part of JTB.

566 points by jsomers 8y ago

The "cow in the field" example reminds me of two heuristics I like: am I right for the wrong reason?; am I wrong for the right reason? Being right for the wrong reason is dangerous: it's not easy to spot, and it perpetuates false sense of security leaving "black swan events" unanticipated. This might occur during debugging as the article points out, or e.g. during A/B testing of a product. Bring wrong for the right reason is just plain frustrating.

chii 8y ago
> Bring wrong for the right reason is just plain frustrating. what's an example of being wrong for the right reason? I can't think of any cases where this happens...
- reinhardt1053 8y ago
  In the context of political forecasting, imagine that you are a defence chief who is faced with an unquantifiable external threat, as the US was by Russia during the Cold War. You can predict that this enemy is a very great threat, or you can say that it isn’t much of a threat, but the outcomes are asymmetric. If you say that the threat is a grave one, and strengthen your defences accordingly, then if the enemy attacks, you were clearly right to take the threat seriously. If the enemy doesn’t attack, you were still right, because you can say that the enemy only didn’t attack because of the action you took. On the other hand, if you dismiss the threat as insignificant, and the enemy attacks, then at best your career comes to a sudden and unpleasant end. So therefore, it is always right to over-emphasise the threats, and if you turn out to be wrong, you were wrong for the right reason.[1] [1] https://wiseinvestment.co.uk/news/antiques-roadshow-tony-yarrow-november-2014 https://wiseinvestment.co.uk/news/antiques-roadshow-tony-yar...
  - chii 8y ago
    > always right to over-emphasise the threats, and if you turn out to be wrong, you were wrong for the right reason. if the audience is not receptive to the concept of opportunity cost, then yes. Unfortunately, a majority of people over-estimate the need for security and thus, allow themselves to be fooled into believing that this over-emphasis, no matter the cost, is justified. Just look at the TSA!
- lmm 8y ago
  Nate Silver is widely seen as having forecast the election "wrong" because he said Trump had a 20% chance of winning. AIUI his position is that his model was right and 20% was an accurate probability.
  - hopler 8y ago
    The essence of probability is being wrong for the right reasons (less often * weight then being right for those same reasons).
- zacherates 8y ago
  Games are a place this comes of frequently. In poker you will often make the "right" (highest EV) play and still lose a given hand. Making the highest odds plays (and being able to figure out what they are) over and over again regardless of how the individual hands turn out is how you win. Obviously, you can also win while making the wrong plays by getting lucky (right for the wrong reasons). Evaluating your play based on the outcome of the hands (did you win or lose) rather than the plays you made with the information you had at the time is called Results Oriented Thinking: https://www.pokerdictionary.net/glossary/results-oriented-thinking/ https://www.pokerdictionary.net/glossary/results-oriented-th... ... and it is a pernicious mistake (with wider applications than just poker :).
- andrewf 8y ago
  My compensation includes company stock. I sell that stock, and some of the proceeds end up in index funds. I do this because I want a diversified portfolio. My employer's stock is up 28% over the last year, S&P 500 is down 6%. I guess my goal going in was to reduce variance, so I wasn't "wrong" about anything. 36% more money would be nice, though. (I haven't changed my strategy as a result)

newsbinator 8y ago

These cases seem to come up often (weekly?) in software development. I wonder how often they come up in other professions. One common case is when you change or delete a comment, and suddenly something breaks. It couldn't have been the comment... but it was working fine before my edit... wasn't it?

veddox 8y ago
Considering the fact that so much of programming is error finding, it's useful (and probably necessary) to have a solid heuristic for quickly determining causal relationships.
C1sc0cat 8y ago
I have had bugs that where fixed by recompiling the entire application
the6threplicant 8y ago
Or the bugs that disappear when you're debugging and then come back hen you're not.
- hobofan 8y ago
  Also known as Heisenbug[0]. [0]: https://en.m.wikipedia.org/wiki/Heisenbug https://en.m.wikipedia.org/wiki/Heisenbug
chrismorgan 8y ago
And then as you look closer, you wonder how it ever worked. Hang on, did it ever work?
- Insanity 8y ago
  I lost quite a few hours trying to restore a feature after I made a commit, only to find out that it was broken for weeks already. Or worse, was not even implemented yet. It's amazing how that just keeps on happening.
8y ago

p2detar 8y ago

This hits close to me as a possible reason why I could never get good at solving geometry problems, solid geometry especially. Most problems would be trivial when one assumes specific preconditions, but my mind was always wandering around, looking at all potential sides of a problem and I could never solve anything. To quote the author from my particular pov: a problem has multiple potential causes, and you have every reason to believe in one of them, even though another is secretly responsible. Reminds me that I need to pick up a book and re-learn the damn thing. It really saddens me that I suck at geometry.

azmodeus 8y ago
I think you should try looking at geometry more like a creation initially then a problem. In this manner you can see assumptions as just building up more simple worlds with those constraints. I have found this view helps when teaching geometry as it empowers the mind.
gdy 8y ago
This is surprising. Russian geometry problems, as I remember them, required creative thinking, which seem to be exactly the opposite to what you are describing.

veddox 8y ago

I had a philosophy lecture last year that included a lot of epistemology (Theory of Knowledge). We talked a fair bit about justified true beliefs, but Gettier only came up in a side note - the professor being more interested in skepticism and the responses thereto. Never would have dreamt of applying that lecture to programming, though.

stareatgoats 8y ago

The 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 based on facts, when in all probability they are merely beliefs fraught with assumptions. Some people might be good at being skeptics in all areas, but I sense most share my own ineptitude here, the reason probably being that any such (incorrect) beliefs don't immediately come back and bite us, as in programming.

james_s_tayler 8y ago
The funny thing about development is what's say 90% of the time you are convinced everything is correct and should be working and it's immensely frustrating because it's not, so you know you are wrong but are unable to offer yourself a more convincing theory and just get stuck until something clicks. But then there's that 10% of the time where you're actually right. And you don't know which one it's going to be. So you have to calm yourself down like "I know I think Im right about this but clearly Im not" but at the same time you have to hold onto that conviction because you're right damnit. Haha.
- hopler 8y ago
  As Raymond Smullyan proved, everyone is either inconsistent or conceited.
  - james_s_tayler 8y ago
    http://www.mit.edu/people/dpolicar/writing/prose/text/epistemologicalNightmare.html http://www.mit.edu/people/dpolicar/writing/prose/text/episte... Reading this made my day.
croo 8y ago
Hard to translate to other domains without a tool to prove you wrong until you are right.

austincheney 8y ago

This 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 input (serendipity) * unexpected output from an unknown input (unintentional) For example I maintain a parser and beautifier for many different languages and many different grammars of those languages. In some cases these languages are really multiple languages (or grammars) imposed upon each other and so the application code must recursively switch to different parsing schemes in the middle of the given input. The more decisions you make in your application code the more complex it becomes and predicting complexity is hard. Since you cannot know of every combination of decisions necessary for every combination of input you do your best to impose super-isolation of tiny internal algorithms. This means you attempt to isolate decision criteria into separated atomic units and those separated atomic units must impose their decision criteria without regard for the various other atomic decision units. Provided well reasoned data structures this is less challenging than it sounds. The goal in all of this is to eliminate unintentional results (see forth bullet point above). It is okay to be wrong, as wrong is a subjective quality, provided each of the atomic decision units are each operating correctly. When that is not enough you add further logic to reduce the interference of the various decision units upon each other. In the case of various external factors imposing interference you must ensure your application is isolated and testable apart from those external factors so that when such defects arise you can eliminate as much known criteria as rapidly as possible. You will never be sure your open-ended system works as intended 100% of the time, but with enough test samples you can build confidence against a variety of unknown combinations.

chii 8y ago
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.
- 8y ago

osharav 8y ago

Interesting to compare this with a simpler term - "Red herring" as something that throws you off course.

mindwork 8y ago

I learned this word, but I'm scared and wondered by it every time. I think it fits here. There is two worlds: believed and true. And when they merge it's called "peripeteia"

Rzor 8y ago
I read the Wikipedia's entry. It seems that it could be better explained as a "plot twist": when your confidence in an outcome is overturned, for better or worse.
kensai 8y ago
Peripeteia in modern Greek means simply "adventure".

thewarrior 8y ago

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 the cause. However he could have increased the probability by going back over commits and confirming that his exact commit introduced the bug. Now the probability goes even higher. But it could still be machine specific a cosmic ray or whatever but the odds are over whelmingly low. In practice causal reasoning also works in a probabilistic fashion. I have a simple model saying that if a planes engine is on then it’s flying. Its a single step probability and so it’s not very accurate in the real world. I do a bunch of experiments and say a plane is flying if the engine is on and air is going over it’s wings faster than a certain speed. Now we have two correlations connected by a causal model that works in many other cases. Hence the probability of it being correct rises. But at the same time we should never mistake direct correlation for causality. But in daily life it’s “good enough”.

TuringTest 8y ago
I like the term "probabilistic survival engine". It explains a lot of phenomena in social trends, religion, politics, and even the practice of science.
- elijahbear 8y ago
  The first time I heard to a brain referred to in this way it was in the scifi book Blindsight by Peter Watts. The book is pretty solid and deals with a lot interesting ideas from cognitive science.
sevensor 8y ago
I'm sad that I had to read so far down the thread to find this comment, which beautifully cuts right through the argument. The problem is the idea of absolute knowledge -- knowledge is probabilistic and contextual. If I'm driving by the field in a car, I may be duped by the cow, but my perception that I'm surrounded by pasture land is more than adequate to support the activity of driving. If on the other hand, I'm Farmer Jones and I'm searching my pasture for Susie the cow, well, I'm not going to be taken in by a statue of a cow for more than a split second anyway.

amelius 8y ago

As software abstractions often put up facades in front of similar abstractions, this is bound to happen to us software developers.

bloak 8y ago

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

hobofan 8y ago
Sure, that is widely useful. You can apply that to the real world if you then add social processes and see "knowledge" or "truth" as shared belief between a chosen set of people (or all of humanity). Then you can go down the whole rabbit hole of beliefe aggregation and voting theory.
yesenadam 8y ago
In an epistemology class once I said to the lecturer "I don't know anything." He said "Don't you know your name?"
- bloak 8y ago
  Isn't that connaître rather than savoir? So much philosophy is playing with words.
- serpix 8y ago
  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 examination and evaporates entirely the closer it is questioned.
  - mbrock 8y ago
    I know my name just like I make a cup of tea. It's not you who makes my cup of tea, right, so who is it? Well, me—the referent of my name, this person right here. That's just part of how our language works. It doesn't seem to matter whether I am a "concrete object" or some swirly pattern of becoming or indeed even an illusion! The English word "I" does not refer to an eternal soul or "atman." If you stare long enough at an ice cream you'll have the marvelous insight that in reality there is no concrete ice cream entity, not least because it melts. Yet people don't go around saying "wake up, there are no ice creams!" Why is that?

coldtea 8y ago

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

chii 8y ago
In science, experiments with a good control is how this problem is removed. And repetition is how to control for coincidences and outlier measurements. Software engineering has many of these Gettier cases, because most software engineers do not follow the scientific method when investigating a problem!
yesenadam 8y ago
Well, why not write them down for us?!
- coldtea 8y ago
  As if they're difficult to derive on one's own? You believe X has cancer because he has the symptoms and you can see an offending black spot on their X-ray. The lab results say the black spot was just a cyst but X indeed has cancer in the same organ.
  - gjm11 8y ago
    That sounds to me like (1) not a clear example of a Gettier case and (2) something that would, in fact, be rare. #1 because one of the reasons for your believing X has cancer is that "he has the symptoms", which (if I'm understanding your example correctly) is in fact a consequence of the cancer he actually has; so, at least to some extent, your belief is causally connected to the true thing you believe in just the way it's not meant to be in a Gettier case. #2 because (so far as I know) it's not at all common to have both (a) cancer in an organ that doesn't show up in your X-ray (or MRI or whatever) and (b) a cyst in the same organ that looks just like cancer in the X-ray/MRI/whatever. I'm not a doctor, but my guess is that this is very unusual indeed. So this isn't a very convincing example of how clear-cut Gettier cases aren't rare: it's neither a clear-cut Gettier case nor something that happens at all often.

deleted 8y ago

[deleted]

Antonio123123 8y ago

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

bryanrasmussen 8y ago

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

pjc50 8y ago

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

daveFNbuck 8y ago
If the real cow (B) was not present, your belief that there was a cow in the field would be justified but not true. Seeing a the fake cow (A) justifies your belief that there's a cow in the field. Adding a real cow (B) that you can't see doesn't remove the justification.
- pjc50 8y ago
  Good point, I've edited "justified" to the full phrase "justified true belief"
  - daveFNbuck 8y ago
    If the belief is both justified and true, how is it not a justified true belief?

RootKitBeerCat 8y ago

So just more simply “red herring”

nga_ 8y ago

Is not this same as coincidence?

mlthoughts2018 8y ago

I actually disagree with the Gettier thought experiment and don’t believe it demonstrates anything interesting. When you see the cow (but it’s really a convincing model), then in your mind, there should be some probability assigned to a variety of outcomes. The main one would be a cow, another one might be that you’re hallucinating, and so on down the list, and somewhere the outcome of cow-like model would be there. From that point you can go in at least two directions, one would be something like a Turing test of the fake cow... beyond a certain point it’s a matter of semantics as to whether it’s a real cow or not, or you could say that your “justified true belief” had to apply to the total state of the field. If you believed there was both a cow model and a cow behind it, that woukd be justified, but the existence of the cow behind the model would not justify incorrect belief that the model was a real cow, in the sense of not admitting uncertainty over the things you see.

ordu 8y ago
Your model of thinking is something like idealized bayesian one, not like human. If your mind decided that something is true with sufficient probability, it then fails to see alternative explanations. This "something" will be a reality to you, not just a belief about reality. But it is not the all. Your mind have some ideas associated with cow you've seen, and those ideas also becomes beliefs of yours. Implicit beliefs, you are probably not aware of them, you could notice this implicit beliefs only if they will begin to contradict evidence in a sharp way. For example, you can implicitly decide that this is a soft tempered cow, that would like to lick you in a face, if you come near. It was not important when you saw the model of a cow, so you didn't become consiously aware of your idea of a cow temper. But it was planted in you idea of reality. Maybe you would have an intention to come near the cow to be licked in the face, and you might be unaware of this intention. Human mind can easily manage such tricks. And it leads to a funny thing. You saw the model of a cow, and it make you believe that there is a cow in the field and that you saw a cow. Then you could find a heap of poo, and you will strengten your beliefs futher. You might find a lot of evidence and it all will be explained under assumption that you saw a cow. And this evidence will strenghten your belief that you will be licked in the face, when you come near the cow. But you didn't saw the cow that made this heap of poo. The real cow is pitch black, with a horns of gigantic size and they are really sharp. The real cow has red glowing eyes and it is going to kill you. But before you see the real cow itself, all the evidence that would point that there is a cow would also reinforce the idea of soft tempered black and white cow. The longer you manage to keep youself oblivious to real cow traits, the more surprised you will become when you find the real cow.

callesgg 8y ago

My own opinion is that knowledge is always relative to a perspective. It is only valid in a context. Nothing is absolute. Example: 1=1 is something i know is true cause i know the rules of mathematics. There is no absolute truth to that.

gerbilly 8y ago
10+3 = 13 when talking about coconuts, but 10+3 = 1 when talking about time[1] [1] In America anyways.

golergka 8y ago

The first example is exactly the reason why I hate rebases and prefer merges and complicated history instead. It may be more complicated, but it doesn't swipe problems under the rug.

hopler 8y ago
That's why in some quarters it's called git debase.

phkahler 8y ago

>> 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 outgrowth of philosophy after all). The whole cow story stinks of telling someone "you're right, but you're also WRONG! Your perception of reality is BROKEN!". To me knowledge is simply having a model of the world that can be used to make useful predictions and communicate (and some other things). Aside from that, it doesn't matter if your model is "grounded in reality" until it fails to work for you, at which time it can be helpful to realize your knowledge (model) needs adjustment. One way to resolving the authors first software issue would be to check a diff between what he committed and the previous production revision - this would quickly uncover the changes he "didn't make". This is an old lesson for me - what I changed may not be limited to what I think I changed. It's a lesson in "trust but verify". There are any number of ways to view it, but in the end we only care about ways that lead to desired outcomes weather they're "right" or not. On a related note, I've found that software is one of the only places where there is a "ground truth" that can be examined and understood in every detail. It's completely deterministic (given a set of common assumptions). I've found the real world - and people in particular - to not be like that at all.

ozy 8y ago
Exactly, one ontology of knowledge is: pointers (names), categories (matchers/recognizers), models (descriptions of systems). The first two have all the problems philosophers talk about. But the last one does not. Not even underdeterminism, unless the system of the model is fundamental or fades into history or is a "wicked" problem.
thejohnconway 8y ago
> 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 and silly things. Being right for the wrong reasons is a common and difficult problem, and some if the solutions to it a really insightful and powerful ideas. > Aside from that, it doesn't matter if your model is "grounded in reality" until it fails to work for you, at which time it can be helpful to realize your knowledge (model) needs adjustment. It might matter a great deal if your model is not grounded in reality - there are situations where that can kill you. It also seems like one of the fundamental aims of science, to have theories fail less often.

ozy 8y ago

Note most gettier cases are plays on our intuitions: What feels like a pointer is actually a category. That is, it feels like it points to one, but it points to many. Like both examples given here: https://en.wikipedia.org/wiki/Gettier_problem https://en.wikipedia.org/wiki/Gettier_problem .

hopler 8y ago
For the C heads, you mean what feels like a pointer is actually an array? :-)

dm03514 8y ago

I can imagine a future where what's true generally describes itself (like terraform on drugs for software :p) Imagine software that is fully self descriptive and would no longer require engineers to individually interpret what's happening because the software would tell us. The system would be a graph of every single component and all possible connections between them, and all variants of each component and state that it could be in. When we introduce a change we would be aware with perfect information about the affect to the states and the paths between them. In the example the Mental Model was at a level too shallow, it should have only affected the paths between the autofocus and the user. But the bug necessitated a larger mental model (the author was considering too small subsection of the graph). I'd hope in the future we could reach a state where the program could have detected that the frame refactor would have an affect on the autofocus and all other components instead of being an implementation detail.

scyclow 8y ago

This reminds me of a recent event at WrestleKingdom 13, a Japanese professional wrestling event where, as you might imagine, pretty much everything is planned and choreographed ahead of time. In the opening match, Kota Ibushi suffered a concussion. Some doctors came out, carried him out on a stretcher, and took him to the back. As it turns out, this was all planned. The doctors were fake, and this course of events was determined ahead of time. But coincidentally, Ibushi _actually_ suffered a real-life concussion in the match. Wrestling always has an interesting relationship with reality.

chasingthewind 8y ago

Another really great work that's related to some of these concepts is "Naming and Necessity" by the philosopher Saul Kripke. https://en.wikipedia.org/wiki/Naming_and_Necessity https://en.wikipedia.org/wiki/Naming_and_Necessity It investigates how we assign names to things and what those names mean and how we can reason about them.

pwaivers 8y ago

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

jemfinch 8y ago
He simply wasn't speaking with precision. If you replace "code change" with "pull request" in his statement, it's JTB.
- llagowivel 8y ago
  That is correct - it is then a JTB - but not a “Gettier”. None of his examples are Gettiers.
- pwaivers 8y ago
  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.
el_cujo 8y ago
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).

bunderbunder 8y ago

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

jeffreyrogers 8y ago

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.

bunderbunder 8y ago
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" should be altered to include a provision that invalidating the justification would imply that the belief is false. So, for example, under that modified definition, the visual evidence couldn't serve as a justification of the belief that there is a cow in the field, because it allows the possibility that it isn't a cow but there still is one in the field. On the other hand, it would work for justifying a belief like, "I can see a cow from here." (Yeah, there's another cow in the field, but it's not the one you think you see.) But, still, that wasn't quite the definition that the mid-century epistemologists who made up Gettier's audience were using. (ETA: Also, the original paper didn't involve cattle at all. Wikipedia has what looks like a good summary: https://en.wikipedia.org/wiki/Gettier_problem#Gettier's_two_original_counterexamples https://en.wikipedia.org/wiki/Gettier_problem#Gettier's_two_...)
- jeffreyrogers 8y ago
  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 :)
  - bunderbunder 8y ago

paulsutter 8y ago

“Justified true belief”? All our knowledge is subjective by definition. We don’t even know whether we’re living in a simulation. Personally I doubt that we’re living in a simulation. But the fact that we could be, demonstrates that we don’t have objective knowledge. No cows needed in the field explain it Philosophy might better be called “the history of flawed thinking”

scotty79 8y ago
Also specific example with a cow is silly. Belief there is a cow in the field is not really justified. It just seems justified to the observer that can't tell difference between model and a real cow.
- deleted 8y ago
  [deleted]
lamacase 8y ago
By what definition? The "notion" of "justified true belief" WAS the definition of knowledge prior to these complications. Just saying "everything is subjective" is more tedious than making meaningful distinctions, in my subjective opinion
- whytaka 8y ago
  I think GP means that the justification of JTB by definition is recursive and thus has no real foundation. To call something 'true' is to know it is 'true'. If we are bothering to debate whether knowledge is possible, JTB is unconvincing.
gnode 8y ago
> We don’t even know whether we’re living in a simulation. I think it's actually worse than this. This scenario suggests that our minds are capable of infallible reasoning yet we may not be able to trust our observations. Really, I don't think we can even trust our own mind, and therefore JTB is undefinable.

voidpointer 8y ago

Somehow, the examples all sound more like a quality and/or testing issue. The workflow seems prone to people rebasing to a buggy state and at that point, in a non-trivial system, all bets are basically off. Basically I need to be able to have a "JTB" about a pull request having undergone enough review and testing before being merged on the master that it doesn't introduce such glaring regressions as cited in the examples. If that cannot be ensured, I'm setting myself up for one goose chase after the other...

rdlecler1 8y ago

Isn’t this just a confounding factor?

azinman2 8y ago

Sounds like (from the cases presented) an over intellectualisation of “coincidences.”

perlgeek 8y ago

> (Yes, I should have caught the bug in testing, and in fact I did notice some odd behavior. But making software is hard!) How often have I noticed some "odd behavior" in testing, and later wasn't able to reproduce it? Some nagging feeling that I broke something remained, but since I've deployed a new version (that fixed something else), and I couldn't reproduce the "odd behavior", I tricked myself into ignoring it. And then I deployed to production, and shit hit the fan. Now I try to pay more attention to those small, nagging feelings of doubt, but it takes conscious effort.

anthonyriggi 8y ago

I don't like this approach. If everyone were to approach a problem with this mentality it would conjure doubt in the entire process. Nothing would ever get done. Question: "how do we know if anything exists?" <--(an extreme example). Answer: "well we don't but it doesn't help us with the realities of the problem at hand." I think this idea introduces confusion and does more harm than good, in my opinion.

gorpomon 8y ago

It's a bit in the weeds, but I think the author has a wrong JTB. They author deployed multiple changes, and just incorrectly assumed that their PR was the one that introduced the bug. They author had incorrect knowledge about what was being deployed. If something in their deploy process indicated that in fact only their code was being deployed then perhaps it's a JTB? But otherwise I think it's just a bit off. However, the gist of it is correct. We often update dependencies or deploy more than we think we do. We have an "us" focused view of our code, and keeping gettier cases in mind helps us break out of that. Just recently I kept thinking that I didn't know how to write a jest test, when in fact I was using a version of Jest which didn't support a certain method. It's easy to think it's our fault, when in fact there can be deeper reasons.

agarden 8y ago

I don't see any of his examples as Gettier cases. He thought his code caused the autofocus problem; it didn't. He thought someone else's push had broken email, but instead the service happened to go down at the same time. A proper Gettier case would be when you write code that you believe to be correct and it does work, but not for the reasons you think it does. Often this eventually bites when some edge case arises. I run into this fairly often playing chess. I calculate out some tactic, decide it works, and play the first move. But my opponent has a move I overlooked which refutes the line I was intending to play. Then I find a move that refutes his, and the tactic ends up working in the end anyway, just not for the reasons I thought it would.

theoh 8y ago
Here's an example that comes to mind: A programmer writing a function refers to a local variable, "status", but thinks they are referring to a global variable. The code works by chance because the variables happen to have the same (fixed) value. The variable shadowing means that the programmer could quite plausibly be confused and believe that they were accessing the global variable ("justification"). "I know I checked the status variable, like I was supposed to".

ppeetteerr 8y ago

This reminds me of how some studies are proven to be true but the reason they are true are not the reasons the author of the study presents. Instead, the true-ness is either a coincidence or a correlation, not causation. These people go on to write books and entire industries are formed around these hypothetical truths and it takes years to undo the damage of the original study (e.g. marshmallow test, jam experiment)

robbrit 8y ago

This is precisely why when dealing with bugs I advise juniors to avoid asking the question, "what changed?" Gettier cases are just one problem that you can face when asking that question. Instead I usually tell them to do it the proper way: start from the bug, and work backwards to understand why that bug is happening. At that point the change that caused the bug becomes obvious, and most of the time we realize that we probably wouldn't have come to that conclusion by looking just at what changed.

RugnirViking 8y ago
This is one of two approaches to the problem of debugging a system. It's advantage is that assuming the programmer can focus on everything they have seen in the debugger for long enough, they can find where the issue arises. It's disadvantage is that as systems get larger, it can get exponentially more time consuming. As programmers we sometimes learn tricks (read: assumptions) to cut down this time, but in the end, the complexity of the system beats all but the very best/most determined. Consider tracing a bug in this manner through the entire code of something as complicated as an operating system. Most of the code you did not write yourself, and you have likely never seen before and no idea what it does. Each new frame the debugger reaches you have to spend time understanding what is happening before determining if this is where the problem occurs, and there are so many frames that it can become difficult to sort through them all.

scottlamb 8y ago

As usual, science has a more practical take on this. Occam's Razor says that if you see a cow shape and hear a cow sound coming from that direction, the most likely explanation is that you're seeing a cow. It retains the possibility this isn't true; the belief can be falsified in several ways: by examining the cow more closely, by the real cow walking out from being the fake one, etc. I think it follows that we never absolutely "know" something. We asymptotically approach knowledge. The scientific method is a way of approaching truth.

gweinberg 8y ago

I don't understand how anyone could have ever thought "justified true belief" was a good definition of knowledge, since the question of "what constitutes justified belief?" is muddier than the question "what constitutes knowledge?" in the first place. Further, even without considering such absurd situations as a real cow hiding behind a fake cow, if you see something that, based on its appearance, almost certainly is a cow, the near certainty doesn't change into absolute certainty just because what appears to be a cow is in fact a cow.

oh_sigh 8y ago

I was surprised when I first learned that this was a novel philosophical concept, because I recall reading a Renaissance-age Italian story(maybe from the De Cameron?) that talks about this: Basically, a man sees his wife walking in the town square with the hat of a friend of theirs, and this leads him to believe that she is cheating with that friend. It turns out that he just offered the hat to her in the market, to help her carry some eggs home, and she was going to return it. So, she goes and returns it, the husband follows her, and it turns out she actually is cheating on the husband with the friend, but the hat hat nothing to do with it.

aaroninsf 8y ago

Always bemused and not a little confused that anyone (most notably, Americans) still spend so much time and energy on analytical philosophy [and its Quine-y assertions about semantics] so many decades after its sort of formal semantics collapsed as a useful way of analyzing natural language. Linguistics (not to mention, comp lit or continental philosophy) departments have an order of magnitude more to say about meaning in natural language and have had for... decades and decades. I just don't get it.

mcgwiz 8y ago

I initially thought this article might be about programming by coincidence [1] or maybe about user experience superstitions [2], but after reading it I wonder if this isn't just about the practice of debugging. Software is complex. When someone begins investigation into a bug, if the fix is not immediately found, it becomes a matter of running down a list of hypothetical causes. As one's experience deepens, both the "running down" and the curating of the "list" become more efficient. IMHO this article is merely about a developer who was unaware of certain hypothetical causes. 1: https://pragprog.com/the-pragmatic-programmer/extracts/coincidence https://pragprog.com/the-pragmatic-programmer/extracts/coinc... 2: https://www.nngroup.com/articles/quality-assurance-ux/ https://www.nngroup.com/articles/quality-assurance-ux/

joe_the_user 8y ago

I know mathematical logic but I don't know much about conventional philosophy. The Gettier argument seems to indicate that a system of false propositions used to arrive at a conclusion could be called "justification" in normal epistemology - that seems a bit disturbing. Being "justified" in believing X means just having some reason, maybe utterly bogus but existing and convincing to you, for believing X (and then X becomes knowledge even if X happens to be true entirely different reasons). How could no one have commented previously if that was how the system was? Edit: the main practical implication of the argument seems to be that one cannot assume that when you have argument for X and when you then you get empirical evidence for X, you cannot take that a proof your argument for X is true. It might be suggestive of the truth of the argument but the structure of the argument also has to be taken into account. But that's been a given scientific and statistical investigations for a long time.

isacikgoz 8y ago

The article was great. I also find philosophy and software correlates occasionally. The response of the author to the gettier cases are expected behavior. In fact it is a blessing. 99% of the time there is a cow, we experienced that before and that’s the reason of our confidence. We easily solve our problems with this approach.

jungler 8y ago

Although many folks have raised the "not Gettier" objection, I would propose that the premise of applying the test to debugging is wrong. Debugging means that your assumptions were already faulty: otherwise the system would not have bugs. That is, the act of programming means working on an unfinished thought, something that can reflect some beliefs but compromises on being an exactly true expression of them. And so the weight of philosophical reasoning should appear at design time. What occurs after that is a discovery phase in which you learn all the ways in which your reasoning was fallacious - both bugs and feature decisions.

karmakaze 8y ago

So just to be clear, a 'gettier' is when something you Believe and have Justification for turns out to be false? Actually True J B 1 1 knowing 1 0 denying 0 1 lucky hunch 0 0 sceptic, default position Actually False J B 1 1 mis-justification: un/incorrectly-verified 1 0 lucky denial of mis-justified 0 1 superstition 0 0 sceptic, default position

hopler 8y ago
No, it's when you get the right answer for the wrong reason, like a math problem solution that has two mistakes that cancel out in the end result, but are still incorrect logic

sunstone 8y ago

Didn't Descartes cover this with "I think therefore I am."? Everything else is varying degrees of speculation.

pitermarx 8y ago

It might be true that even though I have a JTB about something I might be wrong. Nevertheless, I think It would be resonable to act upon a JTB as it it was true. For all effects it is true to the best of my knowledge. This does not mean I shun down new information that might make me to change my JTB. And if having a JTB is not knowledge, what is? What can we know? We can always imagine a world where even our most firm JTB might be false. If a JTB is not a good case to use the word knowledge I don't know what is

thefringthing 8y ago

My reaction Gettier cases as a philosophy minor was that J is the only philosophically interesting part of JTB.