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

Gettiers in software engineering (2019)

jsomers.net

Post reply on HN
Print view View original

51–60 of 222 posts

Re: Gettiers in software engineering (2019)

#51

Post by PaulDavisThe1st »

bee_rider wrote: post #45
PaulDavisThe1st wrote: post #38

Earlier quoted context omitted.

We all carry around multiple falsehoods in our heads that we are convinced are true for a variety of reasons. To say that this is not "knowing" is (as another commenter noted) hair-splitting of the worst kind. In every sense it is a justified belief that happens to be false (we just do not know that yet).

What exactly does it mean to know something then? As distinct from believing it. Just the justification, and then, I guess it doesn't have to be a very good justification if it can be wrong?

I think I would say that knowing means that your belief can resist challenges (to some degree) and that it is capable of driving behavior that changes others' beliefs.

The strength of the justification is, I would suggest, largely subjective.

Re: Gettiers in software engineering (2019)

#52

Post by macintux »

JackFr wrote: post #17
JohnMakin wrote: post #5

I wasn’t aware there was a term for this or that this was not common knowledge - for me I refer to them as “if I fix this, it will break EVERYTHING” cases that come up in my particular line of work frequently, and my peers generally tend to understand as well. Cause/effect in complex symptoms is of course itself complex, which is why the first thing I typically do in any environment is set up metrics and monitoring.…

I’ve come across (possibly written) code that upon close examination seems to only work accidentally — that there are real failures which are somehow hidden by behavior of other systems. The classic and oft heard “How did this ever work?”

Many years ago I was grading my students’ C programs when I found a program that worked without global variables or passing parameters. Instead, every function had the same variables declared in the same order.

Re: Gettiers in software engineering (2019)

#53

Post by CamperBob2 »

jstrieb wrote: post #33

Relevant (deleted, as far as I can tell) tweet: > When I talk to Philosophers on zoom my screen background is an exact replica of my actual background just so I can trick them into having a justified true belief that is not actually knowledge. https://old.reddit.com/r/PhilosophyMemes/comments/gggqkv/get...

Hmm. That seems like a better example of the problem than either of the examples at https://en.wikipedia.org/wiki/Gettier_problem .

The cases cited in the article don't seem to raise any interesting issues at all, in fact. The observer who sees the dark cloud and 'knows' there is a fire is simply wrong, because the cloud can serve as evidence of either insects or a fire and he lacks the additional evidence needed to resolve the ambiguity. Likewise, the shimmer in the distance observed by the desert traveler could signify an oasis or a mirage, so more evidence is needed there as well before the knowledge can be called justified.

I wonder if it would make sense to add predictive power as a prerequisite for "justified true knowledge." That would address those two examples as well as Russell's stopped-clock example. If you think you know something but your knowledge isn't sufficient to make valid predictions, you don't really know it. The Zoom background example would be satisfied by this criterion, as long as intentional deception wasn't in play.

Re: Gettiers in software engineering (2019)

#54

Post by cratermoon »

Question I like to ask my colleagues. Suppose you have a program that passes all the tests. Suppose also that in that program there is a piece of code performs an operation incorrectly. The result of that operation is used in another part of the code that also performs an operation incorrectly, but in such a way that the tested outcome is correct.

Does the code have 0 defects, 1 defect, or 2 defects?

Re: Gettiers in software engineering (2019)

#55

Post by skybrian »

This seems to essentially be saying that coincidences will happen and if you’re fooled by them, sometimes it’s not your fault - they are “justified.” But they may be caused by enemy action: who put that decoy cow there? I guess they even made it move a little?

How careful do you have to be to never be fooled? For most people, a non-zero error rate is acceptable. Their level of caution will be adjusted based on their previous error rate. (Seen in this sense, perfect knowledge in a philosophical sense is a quest for a zero error rate.)

In discussions of how to detect causality, one example is flipping a light switch to see if it makes the light go on and off. How many flips do you need in order to be sure it’s not coincidence?

Re: Gettiers in software engineering (2019)

#56

Post by bhickey »

skybrian wrote: post #55

This seems to essentially be saying that coincidences will happen and if you’re fooled by them, sometimes it’s not your fault - they are “justified.” But they may be caused by enemy action: who put that decoy cow there? I guess they even made it move a little? How careful do you have to be to never be fooled? For most people, a non-zero error rate is acceptable. Their level of caution will be adjusted based on their…

> How careful do you have to be to never be fooled?

This is where Contextualism comes into play. Briefly, your epistemic demands are determined by your circumstances.

https://plato.stanford.edu/entries/contextualism-epistemolog...

Re: Gettiers in software engineering (2019)

#57

Post by motohagiography »

throwawayForMe2 wrote: post #48
namuol wrote: post #13

I always come back to this saying: “Debugging is the art of figuring out which of your assumptions are wrong.” (Attribution unknown)

I always thought of what I learned in some philosophy class, that there are only two ways to generate a contradiction. One way is to reason from a false premise, or as I would put it, something we think is true is not true. The other way is to mix logical levels (“this sentence is false”). I don’t think I ever encountered a bug from mixing logical levels, but the false premise was a common culprit.

some possible examples:

security with cryptography is mostly about logical level problems, where each key or operation forms a layer or box. treating these as discrete states or things is also an abstraction over a seqential folding and mixing process.

debugging a service over a network has the whole stack as logical layers.

most product management is solving technical problems at a higher level of abstraction.

a sequence diagram can be a multi-layered abstraction rotated 90 degrees, etc.

Re: Gettiers in software engineering (2019)

#58

Post by nighthawk454 »

Seems like the terminology of calling it a ‘true’ belief led to some confusion. Of course there is an huge difference between evidence and proof. Correlation is not causation, Godel’s incompleteness theorem, all abstractions are leaky, etc.

Desperation to ‘know’ something for certain can be misleading when coincidence is a lot more common than proof.

Worse yet is extending the feeling of ‘justified’ to somehow ‘lessen’ any wrongness, perhaps instead of a more informative takeaway.

Re: Gettiers in software engineering (2019)

#59

Post by bbor »

kragen wrote: post #44
PaulDavisThe1st wrote: post #23

> true, because it doesn't make sense to "know" a falsehoood That's a problem right there. Maybe that made sense to the Greeks, but it definitely doesn't make any sense in the 21st century. "Knowing" falsehoods is something we broadly acknowledge that we all do.

No, I think many people use a definition of "know" that doesn't include "knowing" falsehoods. Possibly you and they have fundamentally beliefs about the nature of reality, or possibly you are just using different definitions for the same word.

This is the true analytic answer! More fundamentally, “know” is a move in whatever subtype of the English language game you’re playing at the moment, and any discussions we have about what it “really” or “truly” means should be based on those instrumental concerns.

E.g. a neurologist would likely be happy to speak of a brain knowing false information, but a psychologist would insist that that’s not the right word. And that’s not even approaching how this maps to close-but-not-quite-exact translations of the word in other languages…

Re: Gettiers in software engineering (2019)

#60

Post by foobarian »

K0balt wrote: post #6
CleverLikeAnOx wrote: post #4

An old timer I worked with during my first internship called these kinds of issues "the law of coincidental failures" and I took it to heart. I try a lot of obvious things when debugging to ascertain the truth. Like, does undoing my entire change fix the bug?

Yeah, good times. I just recently had one that was a really strong misdirection, ended up being 2 simultaneous other, non related things that conspired to make it look convincingly like my code was not doing what it was supposed to. I even wrote tests to see if I had found a corner-case compiler bug or some broken library code. I was half way through opening an issue on the library when the real culprit became appare…

> corner-case compiler bug

They say never to blame the compiler, and indeed it's pretty much never the compiler. But DNS on the other hand... :-)

Post reply on HN