121–130 of 142 posts
You are only so smart. Once the complexity of the programming model reaches a certain point a debugger is necessary to validate and discover the true nature of a system. Often that point is quite low.
At what point in a neophyte programmer's life should he/she switch from the "immediate & non-stop coding" Khan Academy approach recently discussed here on HN to this Ken Thompson "take a moment and think first" approach? Isn't there the danger that they might not be able or motivated to make the switch?
When I'm trying to understand foreign code in less than enough time, I instrument it (almost always at inputs/outputs) and try to treat functions as black boxes. In an ideal world the black boxes would be working.
Data flows are as important as algorithms. See this thing from Guy Steele.
http://dreamsongs.com/ObjectsHaveNotFailedNarr.html
In particular:
Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this:
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
That was in 1975.
Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language:
"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
That was in 1997, and Raymond was discussing a project coded in C, a procedural language. But for an object-oriented language, I think this aphorism should be reversed, with a twist:
"Show me your interfaces, the contracts for your methods, and I won't usually need your field declarations and class hierarchy; they'll be irrelevant."
I think, however, that practitioners of both procedural and object-oriented languages can agree on Raymond's related point:
"Smart data structures and dumb code works a lot better than the other way around."
Then again, how many times have you found a bug caused by a single line or function call or bit of syntax that didn't do exactly what you thought, that was easily overlooked? Particularly in someone else's code in a language that isn't your main one. I think line level interactive debugging is valuable precisely because it tells you what you really know for certain at the local level, and so lets you reason more effe…
Also, this was pair-programming, both people are making sure that what's written is what's intended to be written and so those issues should be (mostly) gone.
Earlier quoted context omitted.
The best advice I had (from a theoretician) was that I should not try to randomly fix my code but I should understand why it does not work. How to do that? Can you prove (in the mathematical sense) that it always does what you want?
Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.
The advice is to look at the issue as you would a mathematical problem, critically and analytically. Don't use shotgun debugging or quick fixes, but instead try to understand the code thoroughly, what its goal is and how it accomplishes it. Instead of testing with random data, mentally walk through all the possibilities and branches.
This is akin to making a mental model of what you are trying to do, and then verifying that the model is correct, and that your code matches the model.
Earlier quoted context omitted.
I just want to point out that Rob designed much of the logging infrastructure at Google. Take from that what you will.
For people who do not work at Google, is there something unusual (positive or negative) about Google's logging infrastructure?
Earlier quoted context omitted.
Not just that, he coauthored Go together with the coauthor of C.
Didn't realise either of those points. I guess that adequately explains my wondering. What's amusing now are the insecure defensive posts and the downvoting.
Earlier quoted context omitted.
Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.
I don' think the advice is to do a proof, but rather to design and think about it in such a way that you could given enough time.
Earlier quoted context omitted.
Sometimes visual but more often I imagine the code physically. It has weight, or friction, or rigidity, depending on what aspects of the code I'm trying to think about.
Interesting. I should try using that. That is mechanical models. I have come across it(using a mechanical device analogy/metaphor for thinking about something) in other fields( http://www.ribbonfarm.com/2010/06/30/the-philosophers-abacus... ).But never really used it in code/design consciously so far.
Here's a link to the (incomplete) sample chapter on their website for 'The Practice of Programming' on Debugging. http://cm.bell-labs.com/cm/cs/tpop/debugging.html I had this in my wishlist for a while. This just made me buy it. Wonder how different it will be from Code Complete 2.
Earlier quoted context omitted.
I also found that interesting, but not a big surprise since he is one of the co-authors of go...
Agreed - we'd probably all be most productive working in a language we'd designed ourselves, irrespective of the merits or demerits of that language for other programmers.