4 ms·
Yes all the time, debugger for JavaScript and binding.pry for ruby. I don’t understand how people can rely purely on print debugging. I find it much more useful
by mjrbrennan 5y ago
Yes all the time, debugger for JavaScript and binding.pry for ruby. I don’t understand how people can rely purely on print debugging. I find it much more useful to stop and inspect the state and input, and being able to print a backtrace from that point is also valuable.
- juancampa 5y agoNow that I think about it, debugger and logging are orthogonal tools: Debugger: show me everything at this point in time Logging: show me this thing at every point in time
- roca 5y agoWhy not both? It is possible to build a debugger that does both; Pernosco does. (Disclaimer: my baby.) https://pernos.co/about/basics https://pernos.co/about/basics https://pernos.co/about/expressions https://pernos.co/about/expressions
- tudelo 5y agoI rely only on print debugging purely due to lack of investment in my tooling, both by myself and my work environment. The thing is, it always just works. I don't need to think about it. I write code in 5+ languages fairly regularly, with some frameworks that have really weird... "support" for dev tools. But maybe I am just a bad developer with bad excuses. If anyone has been in my shoes and seen the light, would love to hear how you manage jumping in to multiple different languages and keeping a consistent debugging experience (or, at least, more consistent than print).
- weaksauce 5y agouse the best tool for the job. vscode has some ok debugging features for some scripting languages. some of the eclipse backed things like pycharm or jetbrains also has some decent debugging baked in. Anything c/c++/c#/java/swift/kotlin use the appropriate IDE for that(visual studio has really good debugging, xcode is ok, android studio is ok). for 80% of the work I'm doing lately it's vscode + LSP + debugger + neovim as a backend.
- AlotOfReading 5y agoIt really isn't possible to have a consistent cross platform experience outside "closed ecosystems" like the JVM. The problem is that good debugging usually has to integrate very deeply with the language/ecosystem/hardware. Unfortunately programming languages are a mishmash of distinct philosophies implemented differently by people who largely didn't agree with one another, so the debugging experience in most of them is inconsistent and because experience transfers less than you might think, generally abysmal. Moreover, all that deep integration and complexity mean that debuggers are sometimes wholly inappropriate for particular situations and as the use you'll just have to know/learn when that is. But if you can get your hands on a "good" debugger with (e.g.) time travel or reverse debugging, there are entire classes of issues you can instantly solve. It's like having superpowers.