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

121–130 of 185 posts

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

#121

Post by dsr_ »

dotancohen wrote: post #81
chii wrote: post #44

Earlier quoted context omitted.

Yes, i would still classify the software defective. It did not reject backwards explicitly. Just because by accident it works (i.e., the consumer of the output doesn't care) doesn't mean the defect has gone away. To be not defective, the software has to explicitly reject input that it was not designed to handle. Imagine if the software updated with some changes, and the unknown input now produces an incorrect output.…

What would "reject input that it was not designed to handle" look like for an automated car?

When you come around a curve near sunrise or sunset, you may suddenly encounter visual input that overwhelms your sensors. The sun is blinding you. It might overwhelm infrared sensors, too.

If you have alternate sensors, you should trust them them more, and camera systems less.

If you have a sunshade, you should deploy that.

If it is raining, or partially cloudy, the situation may change rapidly.

And perhaps you should slow down, but if you slow down too fast, other vehicles might not be able to avoid you.

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

#122

Post by RosanaAnaDana »

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…

The propensity for mistaking belief for facts certainly take daily hits as a software developer

I think that can be expanded to the whole human race.

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

#123

Post by gnode »

pjc50 wrote: post #40
chii wrote: post #23

Earlier quoted context omitted.

How is 2 & 3 from above different from 4? An unknown input producing correct results is still a problem - the unknown input is the problem. Therefore, i postitulate that anytime an unknown input is possible, the software is defective.

The entire world of AI relies on dealing with "unknown" input?

I would say yes.

There's a saying that when people figure out how to make a computer do something well, that it's no longer in the field of AI. I'd say there's some truth in this, in that for many problems we have solved well (e.g. playing chess), the intelligence is not that of the machine, but of the programmer.

I think that in order for a machine to genuinely be intelligent, it must be capable of original thought, and thus unknown input. Known doesn't necessarily mean specifically considered, but that it could be captured by a known definition. As an example, we can easily define all valid chess moves and checkmates, but we can't define the set of images that look like faces.

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

#124

Post by zrobotics »

skywhopper wrote: post #117
kybernetikos wrote: post #115

Earlier quoted context omitted.

I agree with your point I think, however all of the Gettier cases that I know of seem to be examples of a particular choosing of the fact. In the cow example, he had a justified true belief that there was a cow in the field, but if you had phrased it more naturally as 'I know that that black and white shape I see in that field is a cow', that would not have been true. I suppose the point is just that having a justifi…

Yes, this was my gut reaction to the Gettier exceptions as well. But you picked out the specific detail that seems to clinch it for me: the framing of the "fact" under question matters greatly.

From the author's first example, the framing of the statement was also critical. Rebasing introduced the bug, and it would be a correct statement to say "something I just did broke autofocus." However, it would be incorrect to state "my code in the last commit broke autofocus."

In many ways, programmers need to be as fussy in their statements as philosophers. Since computers are stupid, and do exactly what you specify (usually...) it is important to pay close attention to these exact details. Assuming that the new code contains the bug is incorrect, and proper debugging requires careful attention to these details.

Ive certainly had bugs that were caused by some other, hidden factor like this, and typically the best way to find them is to carefully examine all your assumptions. These may be ugly questions like "is the debugger lying to me?" or "did the compiler actually create the code I intended it to make?" So while these may not be strict Gettier cases (and the author admits this in the article) they nevertheless are fairly common classes of similar problems, and framing them as such does provide a useful framework for approaching them.

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

#125

Post by perlgeek »

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

How often have I noticed some "odd behavior" in testing, and later wasn't able to reproduce it? Some nagging feeling that I broke something remained, but since I've deployed a new version (that fixed something else), and I couldn't reproduce the "odd behavior", I tricked myself into ignoring it.

And then I deployed to production, and shit hit the fan.

Now I try to pay more attention to those small, nagging feelings of doubt, but it takes conscious effort.

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

#126

Post by bunderbunder »

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…

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 really trying to say is that the article isn't describing a situation that relates to Gettier's idea at all. Gettier was talking about situations where you can be right for the wrong reasons. The author was describing a situation where he was simply wrong.

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

#127

Post by beat »

chii wrote: post #44
kstenerud wrote: post #29

Earlier quoted context omitted.

Say you write some movement software. You expect that people will move forward, left, or right. You didn't expect people to try moving backward. People start moving backward, but the software happens to do the right thing due to how it was written. Is the software defective because of your missed expectation?

Yes, i would still classify the software defective. It did not reject backwards explicitly. Just because by accident it works (i.e., the consumer of the output doesn't care) doesn't mean the defect has gone away. To be not defective, the software has to explicitly reject input that it was not designed to handle. Imagine if the software updated with some changes, and the unknown input now produces an incorrect output.…

I've been there, painfully. On my last day on a job, some code I wrote went into production, and the databases started filling up rapidly, to the point where the whole system would halt in a few hours.

Turned out the bug had been latent in the code for 5+ years, predating me. Its data consumption had never been observed before because it was swamped by other data consumption. Changing the architecture to remove that other data brought it to the foreground.

(fwiw, the bug was caused by the difference between 0 and null as a C pointer!)

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

#128

Post by anthonyriggi »

I don't like this approach. If everyone were to approach a problem with this mentality it would conjure doubt in the entire process. Nothing would ever get done. Question: "how do we know if anything exists?" <--(an extreme example). Answer: "well we don't but it doesn't help us with the realities of the problem at hand." I think this idea introduces confusion and does more harm than good, in my opinion.

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

#129

Post by cturner »

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…

Maybe I am arguing the same point as you here, but I am uncomfortable that you are painting the justification criteria as being debatable in these situations.

In particular, I think your criteria for justification is too low. The standard for justification is - however much is necessary to close off the possibility of something being not-wrong.

I find the JTB concept to be useful to reminder us (1) that the concept of knowledge is an ideal and (2) how vulnerable we are to deception.

As an idea survives rounds of falsification, we grow confidence that it is knowledge. But, as Descartes explained in the evil demon scenario, there is room for doubt in virtually everything we think we know. The best we can do is to strive for the ideal.

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

#130

Post by gorpomon »

It's a bit in the weeds, but I think the author has a wrong JTB. They author deployed multiple changes, and just incorrectly assumed that their PR was the one that introduced the bug. They author had incorrect knowledge about what was being deployed. If something in their deploy process indicated that in fact only their code was being deployed then perhaps it's a JTB? But otherwise I think it's just a bit off.

However, the gist of it is correct. We often update dependencies or deploy more than we think we do. We have an "us" focused view of our code, and keeping gettier cases in mind helps us break out of that.

Just recently I kept thinking that I didn't know how to write a jest test, when in fact I was using a version of Jest which didn't support a certain method. It's easy to think it's our fault, when in fact there can be deeper reasons.

Post reply on HN