3 ms·
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
by 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.
- mousepilot 5y agoheh the one thing that needs to go away is me from this conversation. have a good one.