41–50 of 69 posts
I can't be the only one who thinks this is meant to be sarcasm?
Yeah, it's very subtle. He's essentially saying that the TDD approach has made his code is flawless, and he is incapable of producing bugs.
Reminds me of what Edsger Dijkstra wrote, "Let me start with a well-established fact: by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. A major part of the average programmer's activity is devoted to debugging, and from this observation we may conclude that the correctness of his programs —or should we say: their patent incorrectness?— is for him a…
It's a lot easier - and a lot more fun - to deal with specific instances, that are concrete, and can be examined and experimented with on a computer.
Logically, one could also work with proofs with a computer to give the same benefits (e.g. coq proof assistant), but for some reason, it doesn't seem to be as much fun in practice. Perhaps because the abstract versions don't have a direct impact; they aren't "live" (idk).
Reminds me of what Edsger Dijkstra wrote, "Let me start with a well-established fact: by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. A major part of the average programmer's activity is devoted to debugging, and from this observation we may conclude that the correctness of his programs —or should we say: their patent incorrectness?— is for him a…
IIRC Dijkstra advocated constructing a proof of your program first. This also involves debugging, mistakes and trial-and-error, just at a different level. Mathematical representations and proofs are powerful because general and certain; but they aren't magic and don't write themselves. It's a lot easier - and a lot more fun - to deal with specific instances, that are concrete, and can be examined and experimented wit…
Debugging is not fun when your program is leaking memory and you're not sure why, and existing code tools don't tell you why. Especially if you're writing drivers. Sure, stepping through python code might be fun, but not low level c/c++ code where you're in a call stack that's 20 levels deep and half the time you don't have source for the parts the code breaks or asserts on.
Earlier quoted context omitted.
IIRC Dijkstra advocated constructing a proof of your program first. This also involves debugging, mistakes and trial-and-error, just at a different level. Mathematical representations and proofs are powerful because general and certain; but they aren't magic and don't write themselves. It's a lot easier - and a lot more fun - to deal with specific instances, that are concrete, and can be examined and experimented wit…
There is an entire field of CS research on this topic, commonly referred to as formal verification. Some programs are written this way.
You have got to be kidding. Debugging code (especially others') is one of the most heinous activities on this planet. I have lost years of my life fixing what others have created broken (intentionally and otherwise). Years and special occasions that I can never get back because some moron's mission-critical code decided to break, with the ultimatum that no one could leave for $(Holiday of Choice) until fixed. It's be…
There is something terribly satisfying about digging into a problem on a production system that rears its ugly head once a month (requiring a system to be rebooted), brainstorming, setting up test scenarios, getting the bug reproduced, finding the source of the problem, fixing it, testing it and seeing that it has been nailed! (oh, and equally satisfying is seeing the days of uptime on said machine thereafter measured in 3 digit numbers :-D)
And the problem I have in mind was someone elses code. I still enjoyed every minute of the debugging process.
I can kinda relate to having fun fixing bugs, but I think (i addition to some sarcasm) the author is kinda romanticizing debugging. 90% of the time it's no fun, feels like a waste of time and doesn't really provide much satisfaction. Once in a while, though, you do find a really interesting bug and fix it and it feels pretty great!
Reminds me of what Edsger Dijkstra wrote, "Let me start with a well-established fact: by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. A major part of the average programmer's activity is devoted to debugging, and from this observation we may conclude that the correctness of his programs —or should we say: their patent incorrectness?— is for him a…
Next, tell us why goto is bad.