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

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

jsomers.net

Post reply on HN
Print view View original

131–140 of 185 posts

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

#131

Post by kstenerud »

TheOtherHobbes wrote: post #93
Retra wrote: post #89

Earlier quoted context omitted.

You could also argue that your expectations are defective. It is possible to accidentally solve a problem in a correct manner.

Not reliably. It's not professional to design systems that rely on luck. "Let's ignore this edge case and hope we get lucky" is not something you want to see in a software specification.

Or simply acknowledge that your initial specs didn't cover enough, update the specs, test the "new" functionality, and call it a feature in the release notes.

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

#132

Post by abcanthur »

newsbinator wrote: post #3

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?

This gettier concept is new to me, but what's certainly not new is trying to wrap my head around errors in the code. I'm a relatively new developer and I've many times asked more seasoned coworkers about what they do with all the their thinking they perform and possibly code they write during a long error invalidation process. Say you try fixes b,c,d,e,...,z (some of which might be objective improvements, now more robust code) then you finally fix the bug by trying solution A. What do you now do with the code for attempts b through y, and more unclear, all the thoughts in your mind that went into those efforts? Just forehead slap and move on?

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

#133

Post by bch »

20190115 wrote: post #118
bunderbunder wrote: post #85

> A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare. But it’s still a useful idea... At least as presented, I see the idea being used to do more harm than good. Take the first example, with the form not autofocusing. We're already not in a Gettier case, because the author didn't have JTB. The belief that he caused the bug obviously wasn't true. But it wasn't justified, either.…

Philosophy major here. Didn't read the article, but will point out: The significance of Gettier problems as we investigated it is the exposure of an entirely _wrong_ mode of philosophy: philosophizing by intuition. Ultimately, the reason Gettier problems are significant is because for philosophers, the textbook Gettier problem works because _for philosophers_ the problem captures their intuitions of knowledge, and th…

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

And to concretely tie this directly back to software[0]:

Intuition is a wonderful thing. Once you have acquired knowledge and experience in an area, you start getting gut-level feelings about the right way to handle certain situations or problems, and these intuitions can save large amounts of time and effort. However, it’s easy to become overconfident and assume that your intuition is infallible, and this can lead to mistakes.

One area where people frequently misuse their intuition is performance analysis. Developers often jump to conclusions about the source of a performance problem and run off to make changes without making measurements to be sure that the intuition is correct (“Of course it’s the xyz that is slow”). More often than not they are wrong, and the change ends up making the system more complicated without fixing the problem.

[0] https://www.systutorials.com/3525/favorite-sayings-by-john-o...

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

#134

Post by agarden »

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.

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

#135

Post by coldtea »

yesenadam wrote: post #96
coldtea wrote: post #51

Earlier quoted context omitted.

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.

As in, when u write "I can very easily think of examples in medicine, police work (e.g. regarding suspects), accounting, and so on..." but you don't give any, the natural tendency is not to believe you.

That would be the "natural tendency" if I was describing something mysterious and rare that few can fathom. Whereas to me those situations don't seem really as far-fetched or hard for someone to come up on their own.

I didn't write "one can easily" to imply I have some special talent to imagine such situations (and thus had motive to leave examples off to hide the fact that I don't).

I wrote it because I really do believe one can easily find such examples, and wasn't it even worthy to go into details (since I mentioned medicine, police work, etc, I thought the cases I implied where pretty clear too).

In any case, I gave 3 examples in a comment above.

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

#136

Post by whytaka »

lamacase wrote: post #108
paulsutter wrote: post #99

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

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

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.

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

#137

Post by mcguire »

coldtea wrote: post #25

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

Many (most?) wrongful convictions are examples, not of Gettier problems, but of similar issues with JTB.

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

#138

Post by darawk »

bunderbunder wrote: post #126
mdorazio wrote: post #119

Earlier quoted context omitted.

How is it not a JTB? Belief: The pull request broke the search field auto focus. Truth: The pull request did break it. There was an additional reason beyond the pull request unknown to the author, but that's not important to the Truth portion here. Justified: This is the only one you can really debate on, just as philosophers have for a long time. Was he justified in his belief that he broke autofocus? I think so bas…

His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place. What I'm reall…

> His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place.

Yes, but the exact same point can be made about the Gettier case. The problem is inappropriately specified beliefs. The problem with that is that it's impossible ex-ante to know how to correctly specify your beliefs.

For instance, you could just say that the problem with the Gettier case is that the person really just believed there was a "cow-like object" out there. Voila, problem solved! But the fact of the matter is that the person believes there is a cow - just like this person believes that their PR broke the app.

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

#139

Post by theoh »

agarden wrote: post #134

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

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

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

#140

Post by TomMckenny »

bunderbunder wrote: post #85

> A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare. But it’s still a useful idea... At least as presented, I see the idea being used to do more harm than good. Take the first example, with the form not autofocusing. We're already not in a Gettier case, because the author didn't have JTB. The belief that he caused the bug obviously wasn't true. But it wasn't justified, either.…

The auto complete quandary comes from ambiguity of language. The phrase "Auto-complete is broken" is ambiguous in the article encompassing at least two defintions.

I know _that_ auto-complete is broken (I see it, the test fails)

but

I do _not_ know _why_ auto-complete is broken (some other dude did it)

But I still think it's very interesting to talk about if for no other reason than that it clarifies terms and usage.

Post reply on HN