JavaScript debuggers are broken • Hacker News Board

Re: JavaScript debuggers are broken

#121

Post by tobyhinloopen » Thu, Apr 25, 2019, 3:49 PM UTC

kristopolous wrote: post #9

tobyhinloopen wrote: post #2

I have an error reporter in my app and it is completely useless. Stacktraces are usually just starting within some library and never touch app code. I rarely know where the error started, I just have to guess. It sucks.

This is excessively common. Somehow modern debugging is essentially as nuanced as "shit broke". Debugging was far better 20+ years ago under C++ in win32 then it is today - there was working code navigation as well. I don't know how we have fallen so far back in the tooling.

I'm also writing a C app as a hobby. Somehow LLDB is an excellent debugger in my hobby app.

Same with Swift (iOS) development.

Re: JavaScript debuggers are broken

#122

Post by mikeschinkel » Sat, Apr 27, 2019, 5:33 AM UTC

perfunctory wrote: post #34

Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

I would argue that both Brian W. Kernighan and Rob Pike are exceptionally bright individuals, and likely able to hold considerable more abstract complex thought in their heads than the average person.

One of the bigger blindspots I find with exceptionally bright people is they have no concept of how their brains are capable of things that far exceed the capabilities of the average person.

Or said another way, of course Brian W. Kernighan and Rob Pike think that thinking harder is better than experiencing and seeing. Because they can.

#jmtcw

Re: JavaScript debuggers are broken

#123

Post by mikeschinkel » Sat, Apr 27, 2019, 5:38 AM UTC

lugg wrote: post #48

ubercow13 wrote: post #41

Earlier quoted context omitted.

Debuggers implement this but better. You can place a conditional breakpoint containing your code checks, and when execution stops you have access automatically to all the scope you could possibly use to print your output statements without having to write any. You are also free to still think carefully while using a debugger.

No. You're misrepresentating or misunderstanding the claim. It is not about debugging. It is about program design. If you need to step through execution in order to understand and reason about iit then your design is too complex. It is not a claim that print and conditionals are better debugging techniques. It is a claim that having those critical points in execution making assertions and logging warnings is a more p…

> Using a debugger only makes sense if you're dealing with a mess. Fix the mess don't build tools to work with it.

I have long thought if I was unable to use a good IDE debugger I would just change careers. Why? Because often I make the wrong assumption about the data that library or 3rd party functions will return. It is not until I can actually see the data that I realize my assumptions were wrong.

Using a debugger is all about learning, and debuggers make learning faster.

I am often able to code rings around my peers on projects. And I believe the reason is not because I am better or smarter but because I use a good IDE and debugger. And they don't.

Re: JavaScript debuggers are broken

#124

Post by mikeschinkel » Sat, Apr 27, 2019, 5:46 AM UTC

lugg wrote: post #118

almostdeadguy wrote: post #110

Earlier quoted context omitted.

> Like what are you validating that your tests aren't? Why aren't your tests validating it? Your tests are probing your code on a narrow range of inputs (or if you're using something like property testing, potentially a larger but still finite range) drawn from the valid state space that is almost always too large to actually verify. They're also themselves pieces of code that itself can have bugs. Formal methods can…

> Your tests are probing your code on a narrow range of inputs drawn from the valid state space that is almost always too large to actually verify. You don't need to verify all inputs with mathematical certainty. You're writing the code some reasonable shortcuts can be made, some basic understanding of what bugs happen and what kinds of tests provide the best ROI gets you > 80% of the way there. > They're also themse…

> Nobody is policing tool usage here..

> I would be very concerned to see a developer using the debugger on a daily basis especially if they're using it for state validation.

Those two statements seem to be in conflict.

Or maybe I should say that latter is not "policing" so much as "patronizing" in a condescending manner.