A three-page paper that shook philosophy, with lessons for software engineers • Hacker News Board

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

#141

Post by [deleted] » Tue, Jan 15, 2019, 5:45 PM UTC

darawk wrote: post #138

bunderbunder wrote: post #126

Earlier quoted context omitted.

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…

[deleted]

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

#142

Post by ppeetteerr » Tue, Jan 15, 2019, 5:45 PM UTC

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)

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

#143

Post by scottlamb » Tue, Jan 15, 2019, 6:02 PM UTC

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.

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

#144

Post by gweinberg » Tue, Jan 15, 2019, 6:02 PM UTC

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.

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

#145

Post by Retra » Tue, Jan 15, 2019, 6:24 PM UTC

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.

Getting lucky is not the same as relying on luck.

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

#146

Post by Retra » Tue, Jan 15, 2019, 6:26 PM UTC

stareatgoats wrote: post #8

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

My favorite example of this is when someone says "Nobody knows X." As though your own ignorance is as good as everyone's ignorance.

Somebody might know X. And they might know X for all the right reasons. But they probably didn't tell you those reasons, and you probably wouldn't believe them or understand them if they did.

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

#147

Post by oh_sigh » Tue, Jan 15, 2019, 6:50 PM UTC

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.

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

#148

Post by Izkata » Tue, Jan 15, 2019, 6:57 PM UTC

mdorazio wrote: post #119

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

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…

> Truth: The pull request did break it. There was an additional reason beyond the pull request unknown to the author,

Nope:

> At some point, I did a routine rebase on top of this change (and many other unrelated changes).

> [...]

> (Yes, I should have caught the bug in testing, and in fact I did notice some odd behavior. But making software is hard!)

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

#149

Post by fhood » Tue, Jan 15, 2019, 7:05 PM UTC

darawk wrote: post #138

bunderbunder wrote: post #126

Earlier quoted context omitted.

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…

I think I agree with the parent. While this can be made into a Gettier case by messing with the scope of the JTB (pull request broke it vs change broke it) I don't think it really works as intended by the author, and it feels like a poor example in a field teeming with much more straight forwards instances.

I can't simplify the explicit examples I have in my head enough to be worth typing up, but the gist is that I can be correct about the end behavior of a of a piece of code, but can be completely wrong about the code path that it takes to get there. I have good reasons to believe it takes that code path. But I don't know about signal handler or interrupt perhaps, that leads to the same behavior, but does not actually use the code path I traced out.

This happens to me reasonably often while debugging.

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

#150

Post by aaroninsf » Tue, Jan 15, 2019, 7:13 PM UTC

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.