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

41–50 of 185 posts

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

#41

Post by daveFNbuck »

pjc50 wrote: post #39

There's a much closer analogy from software development to the cow story. The cow story is confusing because the cow that you see (A) is fake, but the real one (B) you don't know about. So your belief is not a justified true belief because although the real cow exists, the one your knowledge refers (A) to isn't the real one (B). An intertemporal variant of this is race conditions. There have been lots of problems of…

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.

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

#43

Post by bloak »

yesenadam wrote: post #37
bloak wrote: post #20

To me this seems unhelpful. I'd say there is no "knowledge"; there's only belief. And if you defined knowledge as "justified true belief" then you couldn't apply the definition in practice in the real world because you don't know when something is true. But that's philosophy for you: fun (for some people) but not useful.

In an epistemology class once I said to the lecturer "I don't know anything." He said "Don't you know your name?"

Isn't that connaître rather than savoir?

So much philosophy is playing with words.

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

#44

Post by chii »

kstenerud wrote: post #29
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.

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. Is the defect introduced with the changes? Or was the defect always there?

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

#45

Post by caf »

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…

After a while you are forced to realize that belief isn't the same as reality.

This is what the technique of Rubber Duck Debugging helps with. I wonder if you could translate it to other domains?

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

#46

Post by Rzor »

mindwork wrote: post #14

I learned this word, but I'm scared and wondered by it every time. I think it fits here. There is two worlds: believed and true. And when they merge it's called "peripeteia"

I read the Wikipedia's entry. It seems that it could be better explained as a "plot twist": when your confidence in an outcome is overturned, for better or worse.

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

#48

Post by serpix »

yesenadam wrote: post #37
bloak wrote: post #20

To me this seems unhelpful. I'd say there is no "knowledge"; there's only belief. And if you defined knowledge as "justified true belief" then you couldn't apply the definition in practice in the real world because you don't know when something is true. But that's philosophy for you: fun (for some people) but not useful.

In an epistemology class once I said to the lecturer "I don't know anything." He said "Don't you know your name?"

Not good enough, point to that which knows. Where is it? Who knows it? If there is a knower to that, where is it.. Keep going with this investigation and realize there is no knower, only knowing.

Eastern philosophy has nailed this thousands of years ago and we westerners are up to this day totally in the dark. We actively treat the I as a concrete object that really exists as an entity. It does not hold any closer examination and evaporates entirely the closer it is questioned.

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

#49

Post by mlthoughts2018 »

I actually disagree with the Gettier thought experiment and don’t believe it demonstrates anything interesting.

When you see the cow (but it’s really a convincing model), then in your mind, there should be some probability assigned to a variety of outcomes. The main one would be a cow, another one might be that you’re hallucinating, and so on down the list, and somewhere the outcome of cow-like model would be there.

From that point you can go in at least two directions, one would be something like a Turing test of the fake cow... beyond a certain point it’s a matter of semantics as to whether it’s a real cow or not, or you could say that your “justified true belief” had to apply to the total state of the field. If you believed there was both a cow model and a cow behind it, that woukd be justified, but the existence of the cow behind the model would not justify incorrect belief that the model was a real cow, in the sense of not admitting uncertainty over the things you see.

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

#50

Post by chii »

reinhardt1053 wrote: post #30
chii wrote: post #27

Earlier quoted context omitted.

> Bring wrong for the right reason is just plain frustrating. what's an example of being wrong for the right reason? I can't think of any cases where this happens...

In the context of political forecasting, imagine that you are a defence chief who is faced with an unquantifiable external threat, as the US was by Russia during the Cold War. You can predict that this enemy is a very great threat, or you can say that it isn’t much of a threat, but the outcomes are asymmetric. If you say that the threat is a grave one, and strengthen your defences accordingly, then if the enemy attac…

> always right to over-emphasise the threats, and if you turn out to be wrong, you were wrong for the right reason.

if the audience is not receptive to the concept of opportunity cost, then yes. Unfortunately, a majority of people over-estimate the need for security and thus, allow themselves to be fooled into believing that this over-emphasis, no matter the cost, is justified.

Just look at the TSA!

Post reply on HN