Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript debuggers are broken

samdesota.com

Post reply on HN
Print view View original

41–50 of 124 posts

Re: JavaScript debuggers are broken

#41

Post by ubercow13 »

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.

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.

Re: JavaScript debuggers are broken

#42

Post by flohofwoe »

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.

Just because two famous people didn't like step-debugging doesn't mean that there shouldn't be proper debugging tools beyond printf() ;)

We need to be careful not falling into the cargo-culting trap (same as "Goto considered harmful").

Re: JavaScript debuggers are broken

#43

Post by slaymaker1907 »

wongarsu wrote: post #12
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.

Stack traces for async code are always borderline useless in Javascript. Instead of telling me who called the offending code it just informs me that the code is executed by an scheduler in the event loop.

One feature of CUDA that is nice is that while you can use streams to do stuff asynchronously, you can make it synchronous for easier debugging by setting a flag.

Unfortunately, I don’t think something like this is possible with JS promises since new Promise() is guaranteed to execute in a different iteration of the event loop.

Re: JavaScript debuggers are broken

#44

Post by vmware513 »

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 actually really like to debug Ember.js code. Because of the source map, I always see my code as I wrote it and I know when I'm in the framework's code.

Clean, well written and modern framework, like Ember.js, which supports the developer and help to implement features much faster are great choice and you won't have those problems what were mentioned in the article.

Use great tool not the hyped one...

https://emberjs.com

Re: JavaScript debuggers are broken

#45

Post by spockz »

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.

Debugging Java/Scala works really nice in IntelliJ. It also has support for asynchronous stack traces which means to say that stack traces are carried over asynchronous boundaries. It even works for callbacks.

Edit: Having said this, I still rely more on creating test cases to capture what I think should happen instead of stepping through the code in a white box way.

Re: JavaScript debuggers are broken

#46

Post by vimslayer »

wongarsu wrote: post #12
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.

Stack traces for async code are always borderline useless in Javascript. Instead of telling me who called the offending code it just informs me that the code is executed by an scheduler in the event loop.

Are you transpiling your async functions away? IIRC there's been a lot of work on async function stack traces in V8 but it's obviously useless if they are compiled to some state machine monstrosoty before getting executed.

Re: JavaScript debuggers are broken

#48

Post by lugg »

ubercow13 wrote: post #41
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.

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 productive alternative which precludes debugging in the first place.

> have access automatically to all the scope you could possibly use to print your output statements without having to write any.

If youre in a context where you need this level of access to the state scope you have a ball of mud that needs to be decomposed. You should know what state you have by the failure mode or the failing test at hand.

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

> You are also free to still think carefully while using a debugger.

Yes but again, if you need a debugger it goes to show you don't think carefully very often so maybe telling me you can with a debugger is kind of aoot point when I know you won't.

Re: JavaScript debuggers are broken

#49

Post by flohofwoe »

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…

I'm sorry but this reasoning sounds like elitist rubbish to me, like trying to turn a completely subjective workflow step into a universal law ;)

It's not about a "need to step through because your code is too complex", more about validating the code you just wrote, whether it still "feels right" after it has been dumped from your mental model into actual code.

You may have carefully thought about your program for hours before typing the first line of code, but usually such a splendid plan doesn't survive the first written line. Maybe the super-intuitive API you thought about doesn't quite feel that great in practice, maybe in the end you still didn't think "hard enough" about some problem. Spending time in the debugger to think about solutions is usually better than "just thinking hard" about solving the problem, because you have more data, and can tinker with potential solutions, and finally figure out which of the potential solutions feels best.

It's the same reason you're using a profiler for performance optimization, not just thinking about how to make the code faster (of course that needs to happen too, but it's not enough).

This sort of "validation debugging" in a tight edit-debug loop requires that the debugger runs in the same environment as the source code editor. It must be possible to switch between editing and debugging (and running to the location you edited) in under a second.

Re: JavaScript debuggers are broken

#50

Post by clamiax »

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.

Totally agreed: proper thinking (not hard thinking but proper) on how to design programs makes most debuggers tools useless. Kernighan and Pike, but also Thompson, Ritchie, etc. perfectly understood this 20 years ago. I would not be surprised to learn that they never had the needs to use something like gdb in their nontrivial C programs.

I think JavaScript is a special case because it's too much complex by design.

Post reply on HN