6 ms·

Print debugging also lets me debug precisely how I want, across all languages that allow display of a value at a particular point in code. I'm not dissing folks

Print debugging also lets me debug precisely how I want, across all languages that allow display of a value at a particular point in code. I'm not dissing folks who like the debuggers, but I think theres always going to be some folks who prefer one method over the other. "Print Debugging Should Go Away" is awful presumptive in suggesting that the author is an exclusive authority on how other people go about their workday. I mean the guy probably doesn't even know me.

db48x 5y ago
Carrying water from a well to your house in a bucket every day should go away too. Buckets are fine if they’re all you’ve got, but there’s a reason people install plumbing. More than one, I should say. The difference is that people have proven to be extremely quick to spend time and money on installing plumbing, but these days hardly anyone spends much time improving their editor or other tools. Some companies, like Microsoft, are rich enough to employ dozens or hundreds of engineers on VSCode, and then give it away for free in order to build good–will with a whole generation of programmers. I’m given to understand that Google has teams devoted to developer experience, who spend their time sharping the tools used by Googlers so that most Googlers won’t need to. But most of us don’t spend much time improving our tools, and we mostly can’t buy better ones. It may be presumptuous, but I agree with Roc. If we spend more time on our tools, then print debugging _will_ go away. Not because we’ve forced you to use terrible tools, but because the tools will be so much better than print debugging that you’ll voluntarily start using them.
- mousepilot 5y ago
  sure, but doesn't that sort of require me to believe print debugging is the same as carrying water from a well? I'm happy that debuggers work for folks who like them, and I'm not above using one but for me, the plain old fashioned bandwidth and flexibility I can achieve with logged output just seems to have natural advantages in situations that I seem to find my way into. I'm not saying that "debuggers should go away" because I'm not going to presume that I know what works in someone elses situation, but it seems like this article is actually doing the exact same thing to me. Everyone on that "side" seems to be more emphatic that "print debugging should go away" (the very title), yet for the most part, I'm not seeing print debugger types demanding that interactive debuggers should go away. So there's a disparity in those two attitudes, that implies some advantages on one side or the other, wouldn't it be more productive to list the advantages and let the merits of each approach win out in each situation we programmers find ourselves in? Not to mention my "vendor paranoia", I mean the guy already is making my agent orange act up by almost titling his article "the way mousepilot works should go away," that isn't exactly the sales pitch thats gonna win me over.
  - db48x 5y ago
    > "the way mousepilot works should go away," This is not at all what he is saying. Pernosco makes print debugging even better, faster, more precise, and with less room for errors. It also enhances every other aspect of the debugger, by making them omniscient as well, but nobody will force you to use those features. No one will make you click on a value to trace backwards in the program to find out where that value came from (https://pernos.co/about/dataflow/ https://pernos.co/about/dataflow/), or to debug multiple processes that were running at the same time (https://pernos.co/about/multiprocess/ https://pernos.co/about/multiprocess/). You don’t have to use these advanced capabilities if you don’t want to. Perhaps you’ll never care who the callees of a function are (https://pernos.co/about/callees/ https://pernos.co/about/callees/). Maybe your programs run purely in the terminal, so you never need to click on a pixel to find out who drew it (https://pernos.co/about/screenshots/ https://pernos.co/about/screenshots/). He’s saying that he thinks that once you have the option to do more than just print debugging, you will. Once the debuggers for your favorite languages support these features, you’ll gradually use them more and more, until you hardly ever do “just” print debugging any more. But to get there, someone has to put in the time and effort to make the debuggers for those languages good, not merely acceptable. Or Pernosco has to be extended so that it recognizes the interpreters or runtimes for those languages, so that it can extract the debug info necessary to let you debug your program instead of the interpreter. It can already do this with Chrome and node.js, which both use v8 to run Javascript. (https://pernos.co/about/javascript/ https://pernos.co/about/javascript/) When Python developers see that, they should sit up and wonder what they can do to have that feature for themselves. They can implement it themselves in their own debuggers, or they can extend GDB to provide extra support for the Python interpreter, so that GDB can show the source code of the Python program instead of the source code of the interpreter. Maybe they could help extend Pernosco too. Same with Erlang, and Scheme, and Go, and Java, and so on. > doesn't that sort of require me to believe print debugging is the same as carrying water from a well? Sure. And I get that it’s not as obvious as comparing buckets to pipes. Once you see how a pipe works, and a faucet, it’s pretty hard to deny that they have advantages over buckets in nearly all situations. It’s also hard to argue that buckets have any advantages over pipes at all. But with debugging it’s harder, because the PHP debuggers are awful, and the Python debuggers are barely adequate, and the Bash debugger barely exists, GDB’s command set is about as tidy as kudzu smothering a stand of trees, and so on. It’s easy to argue that these tools are inadequate, and easy to dismiss all debuggers as a result. But the sad state of the debuggers for many languages is due to primarily to neglect, not lack of potential. Even the fact that new languages need to write their own debuggers is sad commentary on the human condition. So yes, print debugging needs to go away, just like poverty and death need to go away. We can solve the problems, we just have to get up and do it.
- reportgunner 5y ago
  >Carrying water from a well to your house in a bucket every day should go away too. Buckets are fine if they’re all you’ve got, but there’s a reason people install plumbing. More than one, I should say. Ok, but I am not going to set up plumbing everywhere I go when a water bottle does the trick. >If we spend more time on our tools, then print debugging will go away. No matter how much time we spend on plumbing will make the water bottle go away.

db48x 5y ago

Carrying water from a well to your house in a bucket every day should go away too. Buckets are fine if they’re all you’ve got, but there’s a reason people install plumbing. More than one, I should say. The difference is that people have proven to be extremely quick to spend time and money on installing plumbing, but these days hardly anyone spends much time improving their editor or other tools. Some companies, like Microsoft, are rich enough to employ dozens or hundreds of engineers on VSCode, and then give it away for free in order to build good–will with a whole generation of programmers. I’m given to understand that Google has teams devoted to developer experience, who spend their time sharping the tools used by Googlers so that most Googlers won’t need to. But most of us don’t spend much time improving our tools, and we mostly can’t buy better ones. It may be presumptuous, but I agree with Roc. If we spend more time on our tools, then print debugging _will_ go away. Not because we’ve forced you to use terrible tools, but because the tools will be so much better than print debugging that you’ll voluntarily start using them.

mousepilot 5y ago
sure, but doesn't that sort of require me to believe print debugging is the same as carrying water from a well? I'm happy that debuggers work for folks who like them, and I'm not above using one but for me, the plain old fashioned bandwidth and flexibility I can achieve with logged output just seems to have natural advantages in situations that I seem to find my way into. I'm not saying that "debuggers should go away" because I'm not going to presume that I know what works in someone elses situation, but it seems like this article is actually doing the exact same thing to me. Everyone on that "side" seems to be more emphatic that "print debugging should go away" (the very title), yet for the most part, I'm not seeing print debugger types demanding that interactive debuggers should go away. So there's a disparity in those two attitudes, that implies some advantages on one side or the other, wouldn't it be more productive to list the advantages and let the merits of each approach win out in each situation we programmers find ourselves in? Not to mention my "vendor paranoia", I mean the guy already is making my agent orange act up by almost titling his article "the way mousepilot works should go away," that isn't exactly the sales pitch thats gonna win me over.
- db48x 5y ago
  > "the way mousepilot works should go away," This is not at all what he is saying. Pernosco makes print debugging even better, faster, more precise, and with less room for errors. It also enhances every other aspect of the debugger, by making them omniscient as well, but nobody will force you to use those features. No one will make you click on a value to trace backwards in the program to find out where that value came from (https://pernos.co/about/dataflow/ https://pernos.co/about/dataflow/), or to debug multiple processes that were running at the same time (https://pernos.co/about/multiprocess/ https://pernos.co/about/multiprocess/). You don’t have to use these advanced capabilities if you don’t want to. Perhaps you’ll never care who the callees of a function are (https://pernos.co/about/callees/ https://pernos.co/about/callees/). Maybe your programs run purely in the terminal, so you never need to click on a pixel to find out who drew it (https://pernos.co/about/screenshots/ https://pernos.co/about/screenshots/). He’s saying that he thinks that once you have the option to do more than just print debugging, you will. Once the debuggers for your favorite languages support these features, you’ll gradually use them more and more, until you hardly ever do “just” print debugging any more. But to get there, someone has to put in the time and effort to make the debuggers for those languages good, not merely acceptable. Or Pernosco has to be extended so that it recognizes the interpreters or runtimes for those languages, so that it can extract the debug info necessary to let you debug your program instead of the interpreter. It can already do this with Chrome and node.js, which both use v8 to run Javascript. (https://pernos.co/about/javascript/ https://pernos.co/about/javascript/) When Python developers see that, they should sit up and wonder what they can do to have that feature for themselves. They can implement it themselves in their own debuggers, or they can extend GDB to provide extra support for the Python interpreter, so that GDB can show the source code of the Python program instead of the source code of the interpreter. Maybe they could help extend Pernosco too. Same with Erlang, and Scheme, and Go, and Java, and so on. > doesn't that sort of require me to believe print debugging is the same as carrying water from a well? Sure. And I get that it’s not as obvious as comparing buckets to pipes. Once you see how a pipe works, and a faucet, it’s pretty hard to deny that they have advantages over buckets in nearly all situations. It’s also hard to argue that buckets have any advantages over pipes at all. But with debugging it’s harder, because the PHP debuggers are awful, and the Python debuggers are barely adequate, and the Bash debugger barely exists, GDB’s command set is about as tidy as kudzu smothering a stand of trees, and so on. It’s easy to argue that these tools are inadequate, and easy to dismiss all debuggers as a result. But the sad state of the debuggers for many languages is due to primarily to neglect, not lack of potential. Even the fact that new languages need to write their own debuggers is sad commentary on the human condition. So yes, print debugging needs to go away, just like poverty and death need to go away. We can solve the problems, we just have to get up and do it.
reportgunner 5y ago
>Carrying water from a well to your house in a bucket every day should go away too. Buckets are fine if they’re all you’ve got, but there’s a reason people install plumbing. More than one, I should say. Ok, but I am not going to set up plumbing everywhere I go when a water bottle does the trick. >If we spend more time on our tools, then print debugging will go away. No matter how much time we spend on plumbing will make the water bottle go away.