Debugging: don't just fix the bug!
Fix the design problem that caused the bug in the first place.
Of course, sometimes, it is merely a typo: you wrote "X" when you meant "Y". But more often, the bug is just a symptom: some part of your code is badly designed or too hard to understand, and that is why the bug occurred. Every bug should be looked upon as an opportunity for improving your design.
Of course, sometimes, it is merely a typo: you wrote "X" when you meant "Y". But more often, the bug is just a symptom: some part of your code is badly designed or too hard to understand, and that is why the bug occurred. Every bug should be looked upon as an opportunity for improving your design.
"too hard to understand"
ReplyDeleteSounds like something someone who thinks computers think would say.
"Sounds like something someone who thinks computers think would say."
DeleteThat sounds like something someone who has never written a program would say. Your code is not hard for the COMPUTER to understand: it just executes whatever you wrote. It is hard for YOU to understand: that's why you wrote the bug you did.
In your effort to play "gotcha" you are instead playing stupid.
When I read that, I wondered, "Is Tom really so dumb that he thinks I meant my code CONFUSED THE COMPUTER, or is he just so anxious to make me look bad that he will say anything?"
DeleteIt wasn't an effort to play gotcha. It was a joke.
DeleteThat said, in response to your retort I'll now put on my "editor for decades" hat: When you write something as open to interpretation as that particular passage, the person to blame when the reader interprets it plausibly but in a way you don't like is you.
This is a bug in Thomas. Alas efforts to improve the design have failed.
Delete"When you write something as open to interpretation as that particular passage, the person to blame when the reader interprets it plausibly..."
DeleteNo Tom. Your interpretation was absurd. It is like hearing a tennis announcer saying "That serve was too hard to handle" and thinking he meant it was too hard for the GROUND to handle.
Sigh ... my statement applied as much to the fact that I wrote a joke you didn't get as to the fact that you wrote something that could so easily be used to make a joke about something you said (and that I agree with) -- that computers don't think.
DeleteNow I have to figure out if you really are as unjustifiably butthurt as you're acting, or whether you're joking back and _I'm_ the one who's not getting it.
"Butthurt"?! What are you talking about: I'm really enjoying myself!
DeleteButthurt = really enjoying myself
DeleteTMI Gene, TMI.
Not that there's anything wrong with that.
Actually... just as an aside ...
ReplyDeleteIn systems where code is generated from a model -- SQL is an example -- it is possible to write something the *interpreter* does not understand, and so it generates very bad code that will never run. You might need to rewrite your SQL (or whatever). But that is certainly not what Thomas meant.
You seem pretty certain about something that isn't true. Here's the sentence in question:
Delete"But more often, the bug is just a symptom: some part of your code is badly designed or too hard to understand"
It's POSSIBLE to stretch that to accommodate the meaning that Gene ascribes to it now, and probably originally intended (at least I assumed that was what he intended).
But on a plain reading, it comes off exactly as, as you put it, "something the *interpreter* does not understand." Which was the basis of the joke, as Gene has posted more than once (and correctly, IMO) on the folly of believing that computers think.
"But on a plain reading..."
DeleteNo Thomas, Ken is describing a very obscure case of machine generated code from a model: the plain reading, what any software engineer would IMMEDIATELY know was meant, is that the code is hard for programmers to understand. There are really only two cases:
One's code is syntactically correct, and the interpreter runs it.
One's code is syntactically incorrect, and the interpreter spits out "SYNATX ERROR."
Even Ken's case is just a metaphor. There is no case of code "hard for the interpreter to understand."
Your "plain reading" refers to a non-existent situation. Perhaps you watched too much "Lost in Space" when you were young.
OK, like I said:
DeleteI can't tell if you're turning the joke back on me in some way by playing dumb, or if you really are married to the idea that a joke which wasn't even meant to particularly be at your expense is some kind of "gotcha" thing of a sort I've never done with you before. So I'll just give up.
FWIW I disagree with Gene about the larger issue, machines can in principle think, but I agree completely that Tom got this absurdly wrong, that hard to understand refers to other programmers, it's ridiculous to read it any other way, and that the tennis ball ground analogy is apt.
DeleteI have read *hundreds* of books and articles on software engineering. They talk repeatedly about not writing code that is "hard to understand." In *every* case, they mean "hard for other programmers to understand." Ken can confirm that this is the "plain reading" of this phrase.
DeleteI left a comment before, maybe it got eaten. Yes Gene. It would never occur to anyone in software it could mean anything else. Tom's reading like imagining when chemists talk about covalent bonds they mean junk bonds issued by the Covalency Bank of Hackensack.
Delete