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

61–70 of 222 posts

Re: Gettiers in software engineering (2019)

#61

Post by dahart »

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?

> What exactly does it mean to know something then?

This is one of the best questions ever, not just for philosophers, but for all us regular plebes to ponder often. The number of things I know is very very small, and the number of things I believe dramatically outnumbers the things I know. I believe, but don’t know, that this is true for everyone. ;) It seems pretty apparent, however, that we can’t know everything we believe, or nothing would ever get done. We can’t all separately experience all things known first-hand, so we rely on stories and the beliefs they invoke in order to survive and progress as a species.

Re: Gettiers in software engineering (2019)

#62

Post by FigurativeVoid »

hamandcheese wrote: post #42

I believe that schrodinger's cat also applies to software bugs. Every time I go looking, I find bugs that I don't believe existed until I observed them.

I have similar belief, but only when it comes to bugs that make me look foolish.

The more likely a bug is to make me look dumb, it will only appear as soon as I ask for help.

Re: Gettiers in software engineering (2019)

#63

Post by mrbombastic »

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 like many things “know” and “believe” are just a shorthand for convenient communication that makes binary something that is really a continuum of probability. That continuum might be something from loose theory to fundamental truth about the universe in our minds. Justifications and evidence move things down the continuum, such that we might assign a probability a thing is true, things can approach 100% probability but never get there, but we as mortals need to operate in the world as if we know things so we say anything close to 100% we “know”. Even though history tells us even some things we believe to be fundamental truths can be discovered to be wrong.

Re: Gettiers in software engineering (2019)

#64

Post by userbinator »

cratermoon wrote: post #54

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?

I can understand 0 and 2, but what's 1? The "I don't know how to count" answer?

Re: Gettiers in software engineering (2019)

#66

Post by salomonk_mur »

ern wrote: post #65

Would a merge instead of a rebase have made it easier to find the bug? (Serious question)

Yes, most likely. Rebase hides the fact the 2 changes happened separately, a merge would make it much easier to see the different avenues that may lead to the bug.

We purposefully try not to do rebases in my team for this reason.

Re: Gettiers in software engineering (2019)

#67

Post by mannykannot »

recursive wrote: post #39
PaulDavisThe1st wrote: post #26

Earlier quoted context omitted.

As long as "your assumptions" includes "I know what I am doing", then OK. But most people tend not to include that in the "your assumptions" list, and frequently it is the source of the bug.

What if you never believed that in the first place?

Then, to be consistent, you should not trust either your deductions or even your choice of axioms.

In other words, it looks like a form of solipsism.

Re: Gettiers in software engineering (2019)

#68

Post by IAmLiterallyAB »

salomonk_mur wrote: post #66
ern wrote: post #65

Would a merge instead of a rebase have made it easier to find the bug? (Serious question)

Yes, most likely. Rebase hides the fact the 2 changes happened separately, a merge would make it much easier to see the different avenues that may lead to the bug. We purposefully try not to do rebases in my team for this reason.

I'm not sure I follow, do you have an example where merging makes things more obvious?

Re: Gettiers in software engineering (2019)

#69

Post by mannykannot »

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.

I agree that it is not often helpful to to avoid the issue by redefining a term in a way not originally intended (though it may be justified if the original definition is predicated on an unjustifiable (and sometimes tacit) assumption.)

Furthermore, OP’s choice of putting “know” in quotes seems to suggest that author is not using the word as conventionally understood (though, of course, orthography is not an infallible guide to intent.)

IMHO, Gettier cases are useful only on that they raise the issue of what constitutes an acceptable justification for a belief to become knowledge.

Gettier clauses are specifically constructed to be about true beliefs, and so do not challenge the idea that facts are true. Instead, one option to resolve the paradox is to drop the justification requirement altogether, but that opens the question of what, if anything, we can know we know. At this point, I feel that I am just following Hume’s footsteps…

Re: Gettiers in software engineering (2019)

#70

Post by akoboldfrying »

lifeisstillgood wrote: post #41

Oh this is such a better and more useful idea than some other common ones like “yak shaving” or DRY Love it

I think those other two are also very useful. I've actually had a lot of traction with introducing "yak shaving" in everyday life situations to non-programmers -- it applies to all kinds of things.

EDIT: Deleted paragraph on DRY that wasn't quite right.

Post reply on HN