16 ms·

Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code a

Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

agumonkey 8y ago
it's odd that debuggers aren't helpful.. aiding in problem space reduction should yield improvements, but maybe depth first tracing is not the right tool here
goto11 8y ago
It is much more efficient to place a breakpoint at the spot where you would have put the print statement and then inspect the values of interest in the debugger. It is a rather false dichotomy to assume that using better tools precludes you from "careful thought".
- matwood 8y ago
  Now that you brought it up this way, I realized that I rarely step through the code. Instead I use break points + inspect like I would a print statement. I find this a much more efficient workflow.
- teambayleaf 8y ago
  A debugger is very useful when you trace a piece of code that 1) you understand well and 2) executes relatively linearly. JavaScript is pretty terrible at both. First of all, most JavaScript apps are just a small chunk of code that sit on frontend frameworks (React etc). This means that using a debugger, you mostly step through framework's internal code base, of which you have a vague understanding at best. Also, an average JavaScript code hops around -- to put it mildly -- crazily, due to the heavy usage of anonymous functions, callbacks and other very cleaver abstractions. This is why placing a bunch of console.log beats tracing with a debugger.
  - curioussavage 8y ago
    What? It jumps around because it’s running in an event loop. Not because JS devs try to do too many clever things. You hope it jumps around often or you might be blocking the loop for too long.
ubercow13 8y ago
Debuggers implement this but better. You can place a conditional breakpoint containing your code checks, and when execution stops you have access automatically to all the scope you could possibly use to print your output statements without having to write any. You are also free to still think carefully while using a debugger.
- lugg 8y ago
  No. You're misrepresentating or misunderstanding the claim. It is not about debugging. It is about program design. If you need to step through execution in order to understand and reason about iit then your design is too complex. It is not a claim that print and conditionals are better debugging techniques. It is a claim that having those critical points in execution making assertions and logging warnings is a more productive alternative which precludes debugging in the first place. > have access automatically to all the scope you could possibly use to print your output statements without having to write any. If youre in a context where you need this level of access to the state scope you have a ball of mud that needs to be decomposed. You should know what state you have by the failure mode or the failing test at hand. Using a debugger only makes sense if you're dealing with a mess. Fix the mess don't build tools to work with it. > You are also free to still think carefully while using a debugger. Yes but again, if you need a debugger it goes to show you don't think carefully very often so maybe telling me you can with a debugger is kind of aoot point when I know you won't.
  - flohofwoe 8y ago
    I'm sorry but this reasoning sounds like elitist rubbish to me, like trying to turn a completely subjective workflow step into a universal law ;) It's not about a "need to step through because your code is too complex", more about validating the code you just wrote, whether it still "feels right" after it has been dumped from your mental model into actual code. You may have carefully thought about your program for hours before typing the first line of code, but usually such a splendid plan doesn't survive the first written line. Maybe the super-intuitive API you thought about doesn't quite feel that great in practice, maybe in the end you still didn't think "hard enough" about some problem. Spending time in the debugger to think about solutions is usually better than "just thinking hard" about solving the problem, because you have more data, and can tinker with potential solutions, and finally figure out which of the potential solutions feels best. It's the same reason you're using a profiler for performance optimization, not just thinking about how to make the code faster (of course that needs to happen too, but it's not enough). This sort of "validation debugging" in a tight edit-debug loop requires that the debugger runs in the same environment as the source code editor. It must be possible to switch between editing and debugging (and running to the location you edited) in under a second.
flohofwoe 8y ago
Just because two famous people didn't like step-debugging doesn't mean that there shouldn't be proper debugging tools beyond printf() ;) We need to be careful not falling into the cargo-culting trap (same as "Goto considered harmful").
- rndgermandude 8y ago
  Sure, blindly accepting what famous people say is problematic. But then again, Kernighan, Pike and Dijkstra became famous because of merit and not because of whatever made Kim Kardashian famous. So it seems reasonable to at least entertain the ideas people like them put forward, instead of dismissing the ideas outright, or dismissing the idea after only the most superficial thinking. Dijkstra make an argument that proper control structures (if-then-else blocks, for-while loops) are better than simulating those with goto. Not that every last use of goto was bad. And if you look at what code looks like these days, seems he was right, or at least most people thought he was. People do not use goto anymore, except for a tiny set of special use cases where it makes sense. E.g. jumping into the "cleanup" end of a function in C, because there is no better way in C to do it, really (no RAII, no python-style with/C# style using, no go-style defer). But you'll hard pressed to find good code, or any code really, that uses goto to implement looping when there are language level loop structures available. The idea here is not that "all and every use of side-stepping debuggers is considered harmful", and not even "just sprinkle some printf()", but to use a combination of good self-checking design (aka defensive programming) that allows to sprinkle printfs()/tracepoints/breakpoints at interesting places instead of blindly stepping through huge blobs of code in a debugger. I like to do that myself, add some error checks and some "output" and it usually works great and is very productive, and having the additional error checks is useful not just then but also in the future... But when it does not work out (legacy code, code other people wrote and I am unfamiliar with) then a step debugger might be a viable alternative especially if the other remaining alternative is "nothing/ask magic eight ball".
  - flohofwoe 8y ago
    Sorry for moving the discussion a little bit off-topic, but I like the "Goto considered harmful" as example of cargo-culting, because Dijkstra wrote this when structured-programming wasn't common, and a goto at that time literally meant "jump anywhere in the entire program", like GOTO works in BASIC. Meanwhile, goto has been tamed and has become a part of the structured-programming-toolset. In C you cannot jump out of the current function with a goto, it's just a slightly more flexible break/continue/return. The meaning of goto has changed completely, yet people still use the "Goto considered harmful" meme as if nothing had changed since Dijkstra wrote that ;)
vmware513 8y ago
I actually really like to debug Ember.js code. Because of the source map, I always see my code as I wrote it and I know when I'm in the framework's code. Clean, well written and modern framework, like Ember.js, which supports the developer and help to implement features much faster are great choice and you won't have those problems what were mentioned in the article. Use great tool not the hyped one... https://emberjs.com https://emberjs.com
- mercer 8y ago
  I have to admit I find it rather puzzling and a little amusing that randomly promoting Ember.js, of all things, is apparently your thing. I mean, I sort of get the intercooler.js dude (if anything, I kind of came around to his perspective and am now all in on Phoenix' LiveView), and I can see how people would be all into Go and whatnot, but Ember is one of those things that I just don't understand anyone being evangelical about..
clamiax 8y ago
Totally agreed: proper thinking (not hard thinking but proper) on how to design programs makes most debuggers tools useless. Kernighan and Pike, but also Thompson, Ritchie, etc. perfectly understood this 20 years ago. I would not be surprised to learn that they never had the needs to use something like gdb in their nontrivial C programs. I think JavaScript is a special case because it's too much complex by design.
sametmax 8y ago
Clearly the guy didn't have to pull out a working PoC in one week with a forced uppon JS framework that just changed its public API and not its doc and that need magic lines just for webpack to not crash. Or that has to pull data from a manually written csv our client uploads at 3 pm on their managed ftp and an untested REST api designed last month by a one man start up, using a legacy client lib that only god and a fired engineer knew how to get to work. Or that has to be done with a trainee designer that knows photoshop but will "learn this css thing on the way" , a remote turkish consulting firm and your boss dog barking next to you because animals are good for moral and we are agile right ? Those theories are good in a lab while writting carefully crafted c for the board you designed the spec for.
- retiredcoder 8y ago
  True, I am big fan of them but there are some legitimate cases where a debugger is so practical. There is a lot of code out there that has very little logical sense per se other than elusive business requirements..
- Tade0 8y ago
  This says much more about the work environment front-end developers are subjected to than anything else.
  - sametmax 8y ago
    Or work with a geographer client that wants to integrate his first terrible, terrible plugin into postgis. Or contribute to a mess of an open source project that your microservice happen to depend on. Or debug your student exercice that found yet a brand new way to crash that you never heard of. Or find what are the side effects of your 3am emergency fix during the last red teaming. Programming is a vast land.
intrasight 8y ago
I agree. And isn't programming about automation and repeatability? A debugger session is manual and one-off. Early in my career I spend a lot more time in debuggers. Now I go months without using a debugger.
- danmaz74 8y ago
  I try not to get into situations where I need a debugger, but when that happens, having a debugger makes a huge difference compared to using print.
  - intrasight 8y ago
    Absolutely. But I think that years of programming has resulted in sort of an internal/mental debugger :)
ninkendo 8y ago
I agree, if I get to write my own code from scratch. Working in a pre-existing codebase with millions upon millions of lines of code written by others over years, having absolutely no idea in what context the function I'm looking at is even called, I need be able to to set breakpoints.
caseymarquis 8y ago
Not a big REPL user I guess.
snarfy 8y ago
Then why create new languages at all? Just 'think harder' about the assembly language someone else wrote.
patrec 8y ago
What would they know? This was written twenty years ago, and as far as I'm aware neither of them had any relevant experience with languages that allow for debugger-driven development, production quality selective tracing or anything of any sophistication. A lot of programming these days involves sending and interrogating complex data via awkward and ill-documented APIs and no amount of abstract a-priori thought or judicious print statements (and good luck printing anything with complex structure with C or Go) is gonna come anywhere close to being able to do an API call, drop into the debugger to see what's going wrong, pretty print deeply nested data sanely and effortlessly and fix up some code or value in the debugger and press on.
- tonyarkles 8y ago
  Sounds like you could benefit from a REPL! Edit: > awkward and ill-documented APIs As someone else mentioned, that sounds more like a work environment problem. If using a debugger allows crap like that to persist, maybe it's better for everyone if we tone down how much we use debuggers.
  - patrec 8y ago
    > As someone else mentioned, that sounds more like a work environment problem. Have you ever used any API by, say, a major cloud provider? For example biquery and google docs are both a buggy mess despite being high profile, long established products. Using libraries like pandas is an exercise in figuring out by trial and error how to get it not to corrupt your data and which of the recommended ways of doing things don't involve a 2 orders of magnitude performance defect. I'm in fact mostly using "repl"-driven development for these types of problems, but of course it's inferior to what I mean by debugger driven, a crippled subset to be precise. The scare quotes are because most languages don't have real read-eval-print-loops either, but something less powerful. Unfortunately to the best of my knowledge there are basically only two languages which support this: Common Lisp and Smalltalk (maybe factor or something else really fringe also does) and I haven't used either in years. What I mean by debugger-driven is that you can literally write your whole program without ever restarting it, from the debugger. By contrast python can't even properly reload a changed module definition. Interestingly it's hard to google good explanatory links, but the point is that you can write some code, run into a problem, and fix the problem right there, in the debugger without aborting the current execution or unwinding the stack. Common Lisp and Smalltalk both have a bunch of unique features that make this type of thing very powerful, for example some function calls another function that's not defined. In python you'd be screwed at this point and restart your program from scratch. In Common lisp you can just write the missing function, compile it and continue the current execution frame as if nothing ever happened. This is because Common Lisp, unlike any remotely popular language allows for resumable exceptions where you can continue from just before the error happened (it also has the usual stack unwinding exceptions). Here's two examples I found : https://www.reddit.com/r/programming/comments/65ct5j/a_pythonist_finds_a_new_home_at_clojure_land/dg9p8rk/ https://www.reddit.com/r/programming/comments/65ct5j/a_pytho... https://malisper.me/debugging-lisp-part-1-recompilation/ https://malisper.me/debugging-lisp-part-1-recompilation/ Concerning low-overhead, selective tracing (that you can run in production without fear of bringing the system down): erlang for example has nice support for this, see e.g. https://github.com/massemanet/redbug https://github.com/massemanet/redbug (although again unfortunately it will be difficult to grok without any prior erlang exposure).
breatheoften 8y ago
Debugger's have uses beyond just debugging. The article mentions a strategy of defining an empty function with a breakpoint when writing code for new functionality -- 'I'll write that code when I hit the breakpoint' can be an extremely fast path to productivity boost. Having the program state in front of you to inspect can really make it easier to write the code for a new piece of functionality.
mistersys 8y ago
Hi. I'm the author of the post. I actually agree here. As soon as I realize it's going to be non-trivial for me to trace the issue with the debugger, more and more instead of setting up complex conditional breakpoints I just step back from the computer and have a think, and white board out my current understanding of how things are working. Usually, I get an "aha!" moment pretty quickly. However, sometimes I don't get that "aha!" moment quickly, it random issues endup taking 30 minutes to hours to trace. What I've come to understand is that's only true because debuggers are so limited. For example, white-boarding out the problem is incredibly useful.. why can't my debugger do that for me, by presenting a number of ways to layout the program and some filters so I can just view my code as graph and watch execution slowed down? Today's debuggers even in their best form are like looking through a tiny peep hole at a picture, I can only see this tiny section... but I want to see the whole picture.
mikeschinkel 8y ago
I would argue that both Brian W. Kernighan and Rob Pike are exceptionally bright individuals, and likely able to hold considerable more abstract complex thought in their heads than the average person. One of the bigger blindspots I find with exceptionally bright people is they have no concept of how their brains are capable of things that far exceed the capabilities of the average person. Or said another way, of course Brian W. Kernighan and Rob Pike think that thinking harder is better than experiencing and seeing. Because they can. #jmtcw

agumonkey 8y ago

it's odd that debuggers aren't helpful.. aiding in problem space reduction should yield improvements, but maybe depth first tracing is not the right tool here

goto11 8y ago

It is much more efficient to place a breakpoint at the spot where you would have put the print statement and then inspect the values of interest in the debugger. It is a rather false dichotomy to assume that using better tools precludes you from "careful thought".

matwood 8y ago
Now that you brought it up this way, I realized that I rarely step through the code. Instead I use break points + inspect like I would a print statement. I find this a much more efficient workflow.
teambayleaf 8y ago
A debugger is very useful when you trace a piece of code that 1) you understand well and 2) executes relatively linearly. JavaScript is pretty terrible at both. First of all, most JavaScript apps are just a small chunk of code that sit on frontend frameworks (React etc). This means that using a debugger, you mostly step through framework's internal code base, of which you have a vague understanding at best. Also, an average JavaScript code hops around -- to put it mildly -- crazily, due to the heavy usage of anonymous functions, callbacks and other very cleaver abstractions. This is why placing a bunch of console.log beats tracing with a debugger.
- curioussavage 8y ago
  What? It jumps around because it’s running in an event loop. Not because JS devs try to do too many clever things. You hope it jumps around often or you might be blocking the loop for too long.

ubercow13 8y ago

Debuggers implement this but better. You can place a conditional breakpoint containing your code checks, and when execution stops you have access automatically to all the scope you could possibly use to print your output statements without having to write any. You are also free to still think carefully while using a debugger.

lugg 8y ago
No. You're misrepresentating or misunderstanding the claim. It is not about debugging. It is about program design. If you need to step through execution in order to understand and reason about iit then your design is too complex. It is not a claim that print and conditionals are better debugging techniques. It is a claim that having those critical points in execution making assertions and logging warnings is a more productive alternative which precludes debugging in the first place. > have access automatically to all the scope you could possibly use to print your output statements without having to write any. If youre in a context where you need this level of access to the state scope you have a ball of mud that needs to be decomposed. You should know what state you have by the failure mode or the failing test at hand. Using a debugger only makes sense if you're dealing with a mess. Fix the mess don't build tools to work with it. > You are also free to still think carefully while using a debugger. Yes but again, if you need a debugger it goes to show you don't think carefully very often so maybe telling me you can with a debugger is kind of aoot point when I know you won't.
- flohofwoe 8y ago
  I'm sorry but this reasoning sounds like elitist rubbish to me, like trying to turn a completely subjective workflow step into a universal law ;) It's not about a "need to step through because your code is too complex", more about validating the code you just wrote, whether it still "feels right" after it has been dumped from your mental model into actual code. You may have carefully thought about your program for hours before typing the first line of code, but usually such a splendid plan doesn't survive the first written line. Maybe the super-intuitive API you thought about doesn't quite feel that great in practice, maybe in the end you still didn't think "hard enough" about some problem. Spending time in the debugger to think about solutions is usually better than "just thinking hard" about solving the problem, because you have more data, and can tinker with potential solutions, and finally figure out which of the potential solutions feels best. It's the same reason you're using a profiler for performance optimization, not just thinking about how to make the code faster (of course that needs to happen too, but it's not enough). This sort of "validation debugging" in a tight edit-debug loop requires that the debugger runs in the same environment as the source code editor. It must be possible to switch between editing and debugging (and running to the location you edited) in under a second.

flohofwoe 8y ago

Just because two famous people didn't like step-debugging doesn't mean that there shouldn't be proper debugging tools beyond printf() ;) We need to be careful not falling into the cargo-culting trap (same as "Goto considered harmful").

rndgermandude 8y ago
Sure, blindly accepting what famous people say is problematic. But then again, Kernighan, Pike and Dijkstra became famous because of merit and not because of whatever made Kim Kardashian famous. So it seems reasonable to at least entertain the ideas people like them put forward, instead of dismissing the ideas outright, or dismissing the idea after only the most superficial thinking. Dijkstra make an argument that proper control structures (if-then-else blocks, for-while loops) are better than simulating those with goto. Not that every last use of goto was bad. And if you look at what code looks like these days, seems he was right, or at least most people thought he was. People do not use goto anymore, except for a tiny set of special use cases where it makes sense. E.g. jumping into the "cleanup" end of a function in C, because there is no better way in C to do it, really (no RAII, no python-style with/C# style using, no go-style defer). But you'll hard pressed to find good code, or any code really, that uses goto to implement looping when there are language level loop structures available. The idea here is not that "all and every use of side-stepping debuggers is considered harmful", and not even "just sprinkle some printf()", but to use a combination of good self-checking design (aka defensive programming) that allows to sprinkle printfs()/tracepoints/breakpoints at interesting places instead of blindly stepping through huge blobs of code in a debugger. I like to do that myself, add some error checks and some "output" and it usually works great and is very productive, and having the additional error checks is useful not just then but also in the future... But when it does not work out (legacy code, code other people wrote and I am unfamiliar with) then a step debugger might be a viable alternative especially if the other remaining alternative is "nothing/ask magic eight ball".
- flohofwoe 8y ago
  Sorry for moving the discussion a little bit off-topic, but I like the "Goto considered harmful" as example of cargo-culting, because Dijkstra wrote this when structured-programming wasn't common, and a goto at that time literally meant "jump anywhere in the entire program", like GOTO works in BASIC. Meanwhile, goto has been tamed and has become a part of the structured-programming-toolset. In C you cannot jump out of the current function with a goto, it's just a slightly more flexible break/continue/return. The meaning of goto has changed completely, yet people still use the "Goto considered harmful" meme as if nothing had changed since Dijkstra wrote that ;)

vmware513 8y ago

I actually really like to debug Ember.js code. Because of the source map, I always see my code as I wrote it and I know when I'm in the framework's code. Clean, well written and modern framework, like Ember.js, which supports the developer and help to implement features much faster are great choice and you won't have those problems what were mentioned in the article. Use great tool not the hyped one... https://emberjs.com https://emberjs.com

mercer 8y ago
I have to admit I find it rather puzzling and a little amusing that randomly promoting Ember.js, of all things, is apparently your thing. I mean, I sort of get the intercooler.js dude (if anything, I kind of came around to his perspective and am now all in on Phoenix' LiveView), and I can see how people would be all into Go and whatnot, but Ember is one of those things that I just don't understand anyone being evangelical about..

clamiax 8y ago

Totally agreed: proper thinking (not hard thinking but proper) on how to design programs makes most debuggers tools useless. Kernighan and Pike, but also Thompson, Ritchie, etc. perfectly understood this 20 years ago. I would not be surprised to learn that they never had the needs to use something like gdb in their nontrivial C programs. I think JavaScript is a special case because it's too much complex by design.

sametmax 8y ago

Clearly the guy didn't have to pull out a working PoC in one week with a forced uppon JS framework that just changed its public API and not its doc and that need magic lines just for webpack to not crash. Or that has to pull data from a manually written csv our client uploads at 3 pm on their managed ftp and an untested REST api designed last month by a one man start up, using a legacy client lib that only god and a fired engineer knew how to get to work. Or that has to be done with a trainee designer that knows photoshop but will "learn this css thing on the way" , a remote turkish consulting firm and your boss dog barking next to you because animals are good for moral and we are agile right ? Those theories are good in a lab while writting carefully crafted c for the board you designed the spec for.

retiredcoder 8y ago
True, I am big fan of them but there are some legitimate cases where a debugger is so practical. There is a lot of code out there that has very little logical sense per se other than elusive business requirements..
Tade0 8y ago
This says much more about the work environment front-end developers are subjected to than anything else.
- sametmax 8y ago
  Or work with a geographer client that wants to integrate his first terrible, terrible plugin into postgis. Or contribute to a mess of an open source project that your microservice happen to depend on. Or debug your student exercice that found yet a brand new way to crash that you never heard of. Or find what are the side effects of your 3am emergency fix during the last red teaming. Programming is a vast land.

intrasight 8y ago

I agree. And isn't programming about automation and repeatability? A debugger session is manual and one-off. Early in my career I spend a lot more time in debuggers. Now I go months without using a debugger.

danmaz74 8y ago
I try not to get into situations where I need a debugger, but when that happens, having a debugger makes a huge difference compared to using print.
- intrasight 8y ago
  Absolutely. But I think that years of programming has resulted in sort of an internal/mental debugger :)

ninkendo 8y ago

I agree, if I get to write my own code from scratch. Working in a pre-existing codebase with millions upon millions of lines of code written by others over years, having absolutely no idea in what context the function I'm looking at is even called, I need be able to to set breakpoints.

caseymarquis 8y ago

Not a big REPL user I guess.

snarfy 8y ago

Then why create new languages at all? Just 'think harder' about the assembly language someone else wrote.

patrec 8y ago

What would they know? This was written twenty years ago, and as far as I'm aware neither of them had any relevant experience with languages that allow for debugger-driven development, production quality selective tracing or anything of any sophistication. A lot of programming these days involves sending and interrogating complex data via awkward and ill-documented APIs and no amount of abstract a-priori thought or judicious print statements (and good luck printing anything with complex structure with C or Go) is gonna come anywhere close to being able to do an API call, drop into the debugger to see what's going wrong, pretty print deeply nested data sanely and effortlessly and fix up some code or value in the debugger and press on.

tonyarkles 8y ago
Sounds like you could benefit from a REPL! Edit: > awkward and ill-documented APIs As someone else mentioned, that sounds more like a work environment problem. If using a debugger allows crap like that to persist, maybe it's better for everyone if we tone down how much we use debuggers.
- patrec 8y ago
  > As someone else mentioned, that sounds more like a work environment problem. Have you ever used any API by, say, a major cloud provider? For example biquery and google docs are both a buggy mess despite being high profile, long established products. Using libraries like pandas is an exercise in figuring out by trial and error how to get it not to corrupt your data and which of the recommended ways of doing things don't involve a 2 orders of magnitude performance defect. I'm in fact mostly using "repl"-driven development for these types of problems, but of course it's inferior to what I mean by debugger driven, a crippled subset to be precise. The scare quotes are because most languages don't have real read-eval-print-loops either, but something less powerful. Unfortunately to the best of my knowledge there are basically only two languages which support this: Common Lisp and Smalltalk (maybe factor or something else really fringe also does) and I haven't used either in years. What I mean by debugger-driven is that you can literally write your whole program without ever restarting it, from the debugger. By contrast python can't even properly reload a changed module definition. Interestingly it's hard to google good explanatory links, but the point is that you can write some code, run into a problem, and fix the problem right there, in the debugger without aborting the current execution or unwinding the stack. Common Lisp and Smalltalk both have a bunch of unique features that make this type of thing very powerful, for example some function calls another function that's not defined. In python you'd be screwed at this point and restart your program from scratch. In Common lisp you can just write the missing function, compile it and continue the current execution frame as if nothing ever happened. This is because Common Lisp, unlike any remotely popular language allows for resumable exceptions where you can continue from just before the error happened (it also has the usual stack unwinding exceptions). Here's two examples I found : https://www.reddit.com/r/programming/comments/65ct5j/a_pythonist_finds_a_new_home_at_clojure_land/dg9p8rk/ https://www.reddit.com/r/programming/comments/65ct5j/a_pytho... https://malisper.me/debugging-lisp-part-1-recompilation/ https://malisper.me/debugging-lisp-part-1-recompilation/ Concerning low-overhead, selective tracing (that you can run in production without fear of bringing the system down): erlang for example has nice support for this, see e.g. https://github.com/massemanet/redbug https://github.com/massemanet/redbug (although again unfortunately it will be difficult to grok without any prior erlang exposure).

breatheoften 8y ago

Debugger's have uses beyond just debugging. The article mentions a strategy of defining an empty function with a breakpoint when writing code for new functionality -- 'I'll write that code when I hit the breakpoint' can be an extremely fast path to productivity boost. Having the program state in front of you to inspect can really make it easier to write the code for a new piece of functionality.

mistersys 8y ago

Hi. I'm the author of the post. I actually agree here. As soon as I realize it's going to be non-trivial for me to trace the issue with the debugger, more and more instead of setting up complex conditional breakpoints I just step back from the computer and have a think, and white board out my current understanding of how things are working. Usually, I get an "aha!" moment pretty quickly. However, sometimes I don't get that "aha!" moment quickly, it random issues endup taking 30 minutes to hours to trace. What I've come to understand is that's only true because debuggers are so limited. For example, white-boarding out the problem is incredibly useful.. why can't my debugger do that for me, by presenting a number of ways to layout the program and some filters so I can just view my code as graph and watch execution slowed down? Today's debuggers even in their best form are like looking through a tiny peep hole at a picture, I can only see this tiny section... but I want to see the whole picture.

mikeschinkel 8y ago

I would argue that both Brian W. Kernighan and Rob Pike are exceptionally bright individuals, and likely able to hold considerable more abstract complex thought in their heads than the average person. One of the bigger blindspots I find with exceptionally bright people is they have no concept of how their brains are capable of things that far exceed the capabilities of the average person. Or said another way, of course Brian W. Kernighan and Rob Pike think that thinking harder is better than experiencing and seeing. Because they can. #jmtcw