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

61–70 of 185 posts

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

#61

Post by ozy »

phkahler wrote: post #57

>> He called them “gettiers” for short. So we used to talk about gettiers all the time, no doubt in part just because it felt clever to talk about them, but also because when you’re a programmer, you run into things that feel like Gettier cases with unusual frequency. Sometimes I think that is what philosophers are doing - feeling clever - perhaps as a defense against some negative inner problem (psychology is an out…

Exactly, one ontology of knowledge is: pointers (names), categories (matchers/recognizers), models (descriptions of systems).

The first two have all the problems philosophers talk about. But the last one does not. Not even underdeterminism, unless the system of the model is fundamental or fades into history or is a "wicked" problem.

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

#62

Post by hopler »

james_s_tayler wrote: post #9
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 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.

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

#63

Post by hopler »

lmm wrote: post #56
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...

Nate Silver is widely seen as having forecast the election "wrong" because he said Trump had a 20% chance of winning. AIUI his position is that his model was right and 20% was an accurate probability.

The essence of probability is being wrong for the right reasons (less often * weight then being right for those same reasons).

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

#64

Post by hopler »

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.

You may be right about knowledge, (relativstic quantum information theory leans in your favor, hi Ron Garrett!) but your dreprectatory definition of knowledge and philosophy covers most humans who have ever existed, not just self titled philosophers.

Anyway your definition is wanting. A religious scientist has two kinds of clearly different beliefs: faith and knowledge. A mathematician has the same two kinds, under different names: axioms and deductions.

Saying that axioms are the same as deductions is a radical claim.

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

#65

Post by hopler »

golergka wrote: post #53

The first example is exactly the reason why I hate rebases and prefer merges and complicated history instead. It may be more complicated, but it doesn't swipe problems under the rug.

That's why in some quarters it's called git debase.

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

#66

Post by lowercased »

jsymolon wrote: post #54
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.…

> To be not defective, the software has to explicitly reject input that it was not designed to handle. In some cases that breaks forward capability. e.g. the case where there is an unknown XML tag. You could reject the tag or message. You'll end up rejecting all future change inputs. If the whitelist of acceptable items is large, it may be acceptable to have a black list however if the above holds, you don't know wha…

The middle ground may be explicitly flag/indicate/log that an unknown situation has been encountered, and 'handle' that by doing something useful (continuing to work without crashing, preventing known "unknown" data from being processed silently, etc). It may not help with forward compat entirely, but it would be explicitly known (and I'd think would be somewhat easier to modify/extend for known unknowns in the future).

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

#67

Post by kensai »

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"

Peripeteia in modern Greek means simply "adventure".

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

#68

Post by dm03514 »

I can imagine a future where what's true generally describes itself (like terraform on drugs for software :p) Imagine software that is fully self descriptive and would no longer require engineers to individually interpret what's happening because the software would tell us. The system would be a graph of every single component and all possible connections between them, and all variants of each component and state that it could be in. When we introduce a change we would be aware with perfect information about the affect to the states and the paths between them.

In the example the Mental Model was at a level too shallow, it should have only affected the paths between the autofocus and the user. But the bug necessitated a larger mental model (the author was considering too small subsection of the graph).

I'd hope in the future we could reach a state where the program could have detected that the frame refactor would have an affect on the autofocus and all other components instead of being an implementation detail.

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

#69

Post by sevensor »

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'm sad that I had to read so far down the thread to find this comment, which beautifully cuts right through the argument. The problem is the idea of absolute knowledge -- knowledge is probabilistic and contextual. If I'm driving by the field in a car, I may be duped by the cow, but my perception that I'm surrounded by pasture land is more than adequate to support the activity of driving. If on the other hand, I'm Farmer Jones and I'm searching my pasture for Susie the cow, well, I'm not going to be taken in by a statue of a cow for more than a split second anyway.

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

#70

Post by thejohnconway »

phkahler wrote: post #57

>> He called them “gettiers” for short. So we used to talk about gettiers all the time, no doubt in part just because it felt clever to talk about them, but also because when you’re a programmer, you run into things that feel like Gettier cases with unusual frequency. Sometimes I think that is what philosophers are doing - feeling clever - perhaps as a defense against some negative inner problem (psychology is an out…

> Sometimes I think that is what philosophers are doing - feeling clever - perhaps as a defense against some negative inner problem (psychology is an outgrowth of philosophy after all).

All science is an outgrowth of philosophy.

It's very frustrating when people look the obviously trivial and sometimes silly examples that philosophers use to elucidate a problem, and take it to mean that they are interested in trivial and silly things. Being right for the wrong reasons is a common and difficult problem, and some if the solutions to it a really insightful and powerful ideas.

> Aside from that, it doesn't matter if your model is "grounded in reality" until it fails to work for you, at which time it can be helpful to realize your knowledge (model) needs adjustment.

It might matter a great deal if your model is not grounded in reality - there are situations where that can kill you. It also seems like one of the fundamental aims of science, to have theories fail less often.

Post reply on HN