Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think we're mostly arguing about how useful the various approaches are. At least for me print debugging is a measure of last resort unless I want to extract some historical data out and I know it won't influence the timing of the issue I'm trying to chase down.

With print debugging your inserting the whole build + deploy + repro setup loop into your debugging, if that's a long time(say 20 minutes in one job I had with production hardware) you're in for a world of pain. I find that just about any other tool usually is an order of magnitude more efficient.

Also even the "step debugger" tools do the same thing you'd do with a print. LLVM for instance uses the IR JIT API to generate watch/eval values: https://releases.llvm.org/9.0.0/docs/ORCv2.html#use-cases

IMO you should relentlessly optimize your iteration times, that's the inner loop of development speed and print debugging fares pretty poorly in that area for all the reasons above.



> I think we're mostly arguing about how useful the various approaches are.

Ah, that's fair.

> At least for me print debugging is a measure of last resort

Right, and I think this depends on the domain. For lots of mature environments, this makes sense -- there's been years for tooling to catch up to the kinds of bugs people run into, possibly corporate money being put into developing debugging tools, etc.

> IMO you should relentlessly optimize your iteration times, that's the inner loop of development speed and[...]

Agreed, though the effect on print debugging on iteration time is very environment-dependent.

> [...]print debugging fares pretty poorly in that area for all the reasons above

Adding console.log to a web app can be a trivial change (though of course reproducing app state is another issue) -- again very environment-dependent.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: