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

161–170 of 185 posts

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

#161

Post by elijahbear »

TuringTest wrote: post #33
thewarrior wrote: post #15

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…

I like the term "probabilistic survival engine". It explains a lot of phenomena in social trends, religion, politics, and even the practice of science.

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.

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

#162

Post by abc_lisper »

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…

This is very interesting. Is there a book that discusses stuff like this?

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

#163

Post by daveFNbuck »

pjc50 wrote: post #58
daveFNbuck wrote: post #41

Earlier quoted context omitted.

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.

Good point, I've edited "justified" to the full phrase "justified true belief"

If the belief is both justified and true, how is it not a justified true belief?

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

#164

Post by ggggtez »

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…

Agreed. This is not some unusual philosophy case. This is a case of a programmer who should know better (rebase is not exactly a no-op change!) ignoring one of the most obvious possibilities.

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

#165

Post by jungler »

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.

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

#166

Post by briantakita »

thewarrior wrote: post #15

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…

An unforeseen issue with probabilistic assessments is the model of the probability space is probably inaccurate.

For example, Nassim Taleb has an argument of IQ being a single-dimentional assessment to a multi-dimensional domain.

I think it's more practical to have a possibility space (where unknown unknowns is a possibility). This removes the need to assess probabilities (which will probably be incorrect) while having being able to per-mutate through the list of possibilities. One can also do logical deductions, based on the possibility space, to assess possible strategies to explore/solve the issues at hand.

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

#167

Post by james_s_tayler »

hopler wrote: post #62
james_s_tayler wrote: post #9

Earlier quoted context omitted.

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

As Raymond Smullyan proved, everyone is either inconsistent or conceited.

http://www.mit.edu/people/dpolicar/writing/prose/text/episte...

Reading this made my day.

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

#168

Post by [deleted] »

mdorazio wrote: post #160
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…

I think you're interpreting the author's belief in a way that you want rather than what he actually says. I read the belief based on this statement from the article: "When I released the new version, I noticed that I’d broken the autofocusing of the search field that was supposed to happen on pageload." That's it. That's the belief - he broke autofocusing when he released the new version. This was true. The later dig…

[deleted]

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

#169

Post by Bartweiss »

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…

I think this is accurate, and not at all pedantic.

The idea that software has 'gettiers' seems accurate and meaningful. To some degree, making and maintaining gettiers is in fact the point of black-boxing. Something like a well-implemented connection pool is designed to let you reason and code as though the proxy didn't exist. If you form beliefs around the underlying system you'll lack knowledge, but your beliefs will be justified and ideally also true.

(One might argue that if you know about the layer of abstraction your belief is no longer justified. I'd argue that it's instead justified by knowing someone tried to replicate the existing behavior - but one form of expertise is noticing when justified beliefs like that have ceased to be true.)

And yet this story isn't about facades breaking down, it's just a common debugging error. Perhaps the precise statement the author quotes is a true and justified, but the logic employed isn't. And it's an important difference: being aware of environment changes you didn't make is a useful programming skill, while being aware of broken abstractions and other gettier problems is a separate useful skill.

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

#170

Post by RugnirViking »

robbrit wrote: post #156

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…

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.

Post reply on HN