Re:A deep dive to find a nasty bug
by evincarofautumn on Wednesday April 04, 2012 @06:09PM
(#3800123)
If you (rightly) preserve code’s sensitivity to alteration for the sake of the computer, then you also have a responsibility to offer clear diagnostics to the programmer. Clang gets this right: people make mistakes, and often they’re hard to spot—no need to make it harder!
Re:A deep dive to find a nasty bug
by jfarmer on Wednesday April 04, 2012 @06:03PM
(#3800099)
If you've never worked with Joe, this is the kind of nonsense he does in his sleep.
I first worked with Joe four years ago. He joined the team knowing no Ruby. What did he do his first week? Diagnose and patch a pretty big bug in MRI's threading implementation.
On a related note, it's always fun to demonstrate code's sensitivity to minor alterations to a non-technical person and see their reactions.
For example, just remove a semi-colon from a random PHP file that gets included in your web app and watch it completely die.
It's a decent way to impress upon people with little technical knowledge the importance of debugging.
(bonus points if you can create an impressive runtime bug that mangles the code's functionality in a flashy way, think mis-spelled variables in PHP)
I first worked with Joe four years ago. He joined the team knowing no Ruby. What did he do his first week? Diagnose and patch a pretty big bug in MRI's threading implementation.
His blog is equally intense: http://timetobleed.com