Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

st.cs.uni-saarland.de

Post reply on HN
Print view View original

1–10 of 42 posts

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#3

Post by hacker_9 »

warpech wrote: post #2

Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99

Used this the other day! Had to track down a visual bug that was introduced in the last 20 commits, but with binary search I could narrow down on the problem a commit at a time and so only had to look at 4 in total.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#4

Post by candiodari »

TLDR of the article: cross-application interfaces (like GDB's cli interface has effectively become) break with version changes. Users don't care about the reasons behind that breakage, and would like to see those treated as bugs. Developers see that attitude as unworkable, and would rather just not care about external interfaces at all.

I always wonder why we gave up on refactoring instead of switching it along so that cross-program changes would become not just possible, but easy and feasible.

What can be done using alt-shift-r in a distributed large scale java app with a GWT frontend and 50 libraries used on the backend, each of which can run distributed across machines ... is baffling.

It shouldn't be !

And now with microservices, it becomes more and more baffling that this worked at one point. That's just horrible. Most of the complaints about it strike me as being complaints that when a toolchain allows for complexity, people make things complex. And of course, that's fair. If you give a 5 year old a laser CNC machine and he finds how to turn it on, things are going to go south quickly. But damn the things you can do with that !

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#5

Post by infinity0 »

candiodari wrote: post #4

TLDR of the article: cross-application interfaces (like GDB's cli interface has effectively become) break with version changes. Users don't care about the reasons behind that breakage, and would like to see those treated as bugs. Developers see that attitude as unworkable, and would rather just not care about external interfaces at all. I always wonder why we gave up on refactoring instead of switching it along so th…

That is not what the paper is about. Stop pushing your own agenda and actually read the thing.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#6

Post by dvfjsdhgfv »

candiodari wrote: post #4

TLDR of the article: cross-application interfaces (like GDB's cli interface has effectively become) break with version changes. Users don't care about the reasons behind that breakage, and would like to see those treated as bugs. Developers see that attitude as unworkable, and would rather just not care about external interfaces at all. I always wonder why we gave up on refactoring instead of switching it along so th…

You definitely have a point (although what you say is only marginally related to the article). However, increasing complexity is inevitable in all aspects, therefore we should be developing tools to manage all this complexity instead of just deciding that "we shouldn't" (which is also an option, see e.g. the recent unikernels trend.)

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#7

Post by kossmoboleat »

I took several courses with professor Zeller and with post-docs at his chair. We applied the described concept of "delta debugging" to finding programming errors in python programs.

Suprisingly it was possible to implement this in the course although one had to fiddle so much with Python's internals.

Zeller's chair homepage has a lot of additional infos. Here's a page on how the idea evolved after the initial paper in 1999: https://www.st.cs.uni-saarland.de/dd/

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#9

Post by atonse »

We once had a bug that would cause a failure in our test suite, but very rarely. It was so rare that it would just "go away" and not show up for weeks. So we thought it was odd (maybe bad test data, etc) but moved on.

When we decided to look into it when we had some downtime, we found out that it was a date bug that only reared its head on the 31st day of the month, hence only happening every two months.

I'm not sure bisect would've helped but still was really funny when we did find the issue.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#10

Post by michaelcampbell »

atonse wrote: post #9

We once had a bug that would cause a failure in our test suite, but very rarely. It was so rare that it would just "go away" and not show up for weeks. So we thought it was odd (maybe bad test data, etc) but moved on. When we decided to look into it when we had some downtime, we found out that it was a date bug that only reared its head on the 31st day of the month, hence only happening every two months. I'm not sure…

Was this the kind of test that only ran once a day?
Post reply on HN