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

21–30 of 185 posts

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

#21

Post by Insanity »

chrismorgan wrote: post #19
newsbinator wrote: post #3

These cases seem to come up often (weekly?) in software development. I wonder how often they come up in other professions. One common case is when you change or delete a comment, and suddenly something breaks. It couldn't have been the comment... but it was working fine before my edit... wasn't it?

And then as you look closer, you wonder how it ever worked. Hang on, did it ever work?

I lost quite a few hours trying to restore a feature after I made a commit, only to find out that it was broken for weeks already. Or worse, was not even implemented yet.

It's amazing how that just keeps on happening.

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

#22

Post by hobofan »

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.

Sure, that is widely useful.

You can apply that to the real world if you then add social processes and see "knowledge" or "truth" as shared belief between a chosen set of people (or all of humanity). Then you can go down the whole rabbit hole of beliefe aggregation and voting theory.

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

#23

Post by chii »

austincheney wrote: post #10

This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are: * expected output from a known input (intention) * unexpected output from a known input (defect) * expected output from an unknown inp…

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.

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

#24

Post by hobofan »

the6threplicant wrote: post #17
newsbinator wrote: post #3

These cases seem to come up often (weekly?) in software development. I wonder how often they come up in other professions. One common case is when you change or delete a comment, and suddenly something breaks. It couldn't have been the comment... but it was working fine before my edit... wasn't it?

Or the bugs that disappear when you're debugging and then come back hen you're not.

Also known as Heisenbug[0].

[0]: https://en.m.wikipedia.org/wiki/Heisenbug

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

#25

Post by coldtea »

>A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare.

I beg to differ. Besides the examples in programming the author gave, I can very easily think of examples in medicine, police work (e.g. regarding suspects), accounting, and so on...

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

#26

Post by chii »

coldtea wrote: post #25

> A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare. I beg to differ. Besides the examples in programming the author gave, I can very easily think of examples in medicine, police work (e.g. regarding suspects), accounting, and so on...

In science, experiments with a good control is how this problem is removed. And repetition is how to control for coincidences and outlier measurements.

Software engineering has many of these Gettier cases, because most software engineers do not follow the scientific method when investigating a problem!

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

#27

Post by chii »

austinjp wrote: post #2

The "cow in the field" example reminds me of two heuristics I like: am I right for the wrong reason?; am I wrong for the right reason? Being right for the wrong reason is dangerous: it's not easy to spot, and it perpetuates false sense of security leaving "black swan events" unanticipated. This might occur during debugging as the article points out, or e.g. during A/B testing of a product. Bring wrong for the right r…

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

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

#28

Post by naniwaduni »

chii wrote: post #23
austincheney wrote: post #10

This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are: * expected output from a known input (intention) * unexpected output from a known input (defect) * expected output from an unknown inp…

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.

Well, it's harder to tell something's wrong when the output looks right.

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

#29

Post by kstenerud »

chii wrote: post #23
austincheney wrote: post #10

This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are: * expected output from a known input (intention) * unexpected output from a known input (defect) * expected output from an unknown inp…

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?

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

#30

Post by reinhardt1053 »

chii wrote: post #27
austinjp wrote: post #2

The "cow in the field" example reminds me of two heuristics I like: am I right for the wrong reason?; am I wrong for the right reason? Being right for the wrong reason is dangerous: it's not easy to spot, and it perpetuates false sense of security leaving "black swan events" unanticipated. This might occur during debugging as the article points out, or e.g. during A/B testing of a product. Bring wrong for the right r…

> 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 attacks, you were clearly right to take the threat seriously. If the enemy doesn’t attack, you were still right, because you can say that the enemy only didn’t attack because of the action you took. On the other hand, if you dismiss the threat as insignificant, and the enemy attacks, then at best your career comes to a sudden and unpleasant end. So therefore, it is always right to over-emphasise the threats, and if you turn out to be wrong, you were wrong for the right reason.[1]

[1] https://wiseinvestment.co.uk/news/antiques-roadshow-tony-yar...

Post reply on HN