4 ms·

tbh I wish editors would get rid of "log breakpoints". Teach people to use the conditional breakpoint and just enter `console.log(...)` instead, it's overwhelm

by Groxx 9y ago

tbh I wish editors would get rid of "log breakpoints". Teach people to use the conditional breakpoint and just enter `console.log(...)` instead, it's overwhelmingly more powerful. A specialized "log breakpoint" doesn't teach them that it's just code. (I've run into quite a few programmers who have known about log breakpoints for years, used them fairly heavily, but never knew you could do things in conditional breakpoints) Want to collect all values of something as your code runs? conditional breakpoint: `x = (x || []).append(val)` and then print it whenever you feel like it. Log breakpoint? spit it out each time and... browse by hand? hope nothing's logged in between? bah.

setr 9y ago
I've never even seen log breakpoints before but is it really just a wrapper for inserting console.log()? That seems... kinda useless. From the video, it doesn't even look like it's that easy to clean-up once you're done with them (though maybe there's a remove-all function) >Teach people to use the conditional breakpoint and just enter `console.log(...)` instead, it's overwhelmingly more powerful. If you're going to print things for insight at breakpoint time, wouldn't it make more sense to just use watch expressions?
- Groxx 9y ago
  "stop the world and view expression(X)" is time-consuming when you're trying to discover patterns that you can later be more selective about (e.g. to turn them into a conditional breakpoint). With logs you can pretty trivially spit out thousands of them and eyeball / grep / etc however you need, which could take hours if you had to stop each time, and didn't have specialized tools to help you search for needles in the haystack. But very frequently yes, all you need is a breakpoint and an expression, and hit "continue" a few times. I absolutely do that when I can. --- As to "just a wrapper for console.log", yes. It's a bit of an infection, though I'm not seeing as many as I used to, so maybe we're fighting it off. but e.g.: jetbrains has stuff like "evaluate and log": https://www.jetbrains.com/help/phpstorm/configuring-breakpoints.html https://www.jetbrains.com/help/phpstorm/configuring-breakpoi... Visual Studio has "condition" and "action" options for breakpoints: https://msdn.microsoft.com/en-us/library/5557y8b4.aspx https://msdn.microsoft.com/en-us/library/5557y8b4.aspx one of which is "log a message": http://www.visualmicro.com/page/User-Guide.aspx?doc=Working-With-Breakpoints-When-Hit.html http://www.visualmicro.com/page/User-Guide.aspx?doc=Working-... (mindlessly copying this UI, because what VS does is Good™ (it generally is!), used to be more common from what I can remember) even Chrome [1] and MDN [2] refer to conditional breakpoints, but only mention "will stop when condition is true", not "by the way you can mutate state in here, call funcs, anything you like". [1]: https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints#conditional-loc https://developers.google.com/web/tools/chrome-devtools/java... [2]: https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Set_a_conditional_breakpoint https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_... --- It's oddly crippling to not know this kind of stuff. Ever had a bug, and you wanted to see how it would behave if var X was the right value? You can just override it in a conditional breakpoint and "fix" the bug without rebuilding, to see what happens. Thankfully there are at least a handful of people who have realized this, despite docs essentially never calling it out: https://davidwalsh.name/debugging-conditional-breakpoints https://davidwalsh.name/debugging-conditional-breakpoints In many languages, a debugger is very nearly a REPL. Wish Java would have a REPL? Sure, a simple CLI command would be nice, but I've done "live" coding of android apps for years. Just add a periodic callback to the main thread with a disabled breakpoint - once there, modify your views in the expression editor, and your app - on your phone - updates in the very next view tick. There are limitations, like (kinda) not being able to import new things, but they're not hard to work within and the time savings can be immense.
cup-of-tea 9y ago
Don't teach people to program using IDEs if you actually want them to learn how things work.
- Groxx 9y ago
  Don't give people saws until they spend years chopping down trees with axes. Or maybe they should start out by punching them down, we weren't born with axes you know, and you won't understand a saw until you feel the wood fibers buckling under your knuckles. No. This stance is complete nonsense. People who don't want to learn how things work won't learn either way, but an IDE can at least make them safer and more productive. For people who do, an IDE can magnify your abilities quite a lot. All of which is true for any (decent[1]) tool in any field. [1] here, have a twitter rant. You're advocating for the Hole Hawg: https://twitter.com/myrrlyn/status/980148201456943104 https://twitter.com/myrrlyn/status/980148201456943104

by Groxx 9y ago

setr 9y ago

I've never even seen log breakpoints before but is it really just a wrapper for inserting console.log()? That seems... kinda useless. From the video, it doesn't even look like it's that easy to clean-up once you're done with them (though maybe there's a remove-all function) >Teach people to use the conditional breakpoint and just enter `console.log(...)` instead, it's overwhelmingly more powerful. If you're going to print things for insight at breakpoint time, wouldn't it make more sense to just use watch expressions?

Groxx 9y ago
"stop the world and view expression(X)" is time-consuming when you're trying to discover patterns that you can later be more selective about (e.g. to turn them into a conditional breakpoint). With logs you can pretty trivially spit out thousands of them and eyeball / grep / etc however you need, which could take hours if you had to stop each time, and didn't have specialized tools to help you search for needles in the haystack. But very frequently yes, all you need is a breakpoint and an expression, and hit "continue" a few times. I absolutely do that when I can. --- As to "just a wrapper for console.log", yes. It's a bit of an infection, though I'm not seeing as many as I used to, so maybe we're fighting it off. but e.g.: jetbrains has stuff like "evaluate and log": https://www.jetbrains.com/help/phpstorm/configuring-breakpoints.html https://www.jetbrains.com/help/phpstorm/configuring-breakpoi... Visual Studio has "condition" and "action" options for breakpoints: https://msdn.microsoft.com/en-us/library/5557y8b4.aspx https://msdn.microsoft.com/en-us/library/5557y8b4.aspx one of which is "log a message": http://www.visualmicro.com/page/User-Guide.aspx?doc=Working-With-Breakpoints-When-Hit.html http://www.visualmicro.com/page/User-Guide.aspx?doc=Working-... (mindlessly copying this UI, because what VS does is Good™ (it generally is!), used to be more common from what I can remember) even Chrome [1] and MDN [2] refer to conditional breakpoints, but only mention "will stop when condition is true", not "by the way you can mutate state in here, call funcs, anything you like". [1]: https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints#conditional-loc https://developers.google.com/web/tools/chrome-devtools/java... [2]: https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Set_a_conditional_breakpoint https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_... --- It's oddly crippling to not know this kind of stuff. Ever had a bug, and you wanted to see how it would behave if var X was the right value? You can just override it in a conditional breakpoint and "fix" the bug without rebuilding, to see what happens. Thankfully there are at least a handful of people who have realized this, despite docs essentially never calling it out: https://davidwalsh.name/debugging-conditional-breakpoints https://davidwalsh.name/debugging-conditional-breakpoints In many languages, a debugger is very nearly a REPL. Wish Java would have a REPL? Sure, a simple CLI command would be nice, but I've done "live" coding of android apps for years. Just add a periodic callback to the main thread with a disabled breakpoint - once there, modify your views in the expression editor, and your app - on your phone - updates in the very next view tick. There are limitations, like (kinda) not being able to import new things, but they're not hard to work within and the time savings can be immense.

cup-of-tea 9y ago

Don't teach people to program using IDEs if you actually want them to learn how things work.

Groxx 9y ago
Don't give people saws until they spend years chopping down trees with axes. Or maybe they should start out by punching them down, we weren't born with axes you know, and you won't understand a saw until you feel the wood fibers buckling under your knuckles. No. This stance is complete nonsense. People who don't want to learn how things work won't learn either way, but an IDE can at least make them safer and more productive. For people who do, an IDE can magnify your abilities quite a lot. All of which is true for any (decent[1]) tool in any field. [1] here, have a twitter rant. You're advocating for the Hole Hawg: https://twitter.com/myrrlyn/status/980148201456943104 https://twitter.com/myrrlyn/status/980148201456943104