"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.:
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".
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.
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.
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-breakpoi...
Visual Studio has "condition" and "action" options for breakpoints: 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-... (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/java...
[2]: 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
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.