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

101–110 of 124 posts

Re: JavaScript debuggers are broken

#101

Post by breatheoften »

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.

Debugger's have uses beyond just debugging.

The article mentions a strategy of defining an empty function with a breakpoint when writing code for new functionality -- 'I'll write that code when I hit the breakpoint' can be an extremely fast path to productivity boost. Having the program state in front of you to inspect can really make it easier to write the code for a new piece of functionality.

Re: JavaScript debuggers are broken

#102

Post by danmaz74 »

intrasight wrote: post #58
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 agree. And isn't programming about automation and repeatability? A debugger session is manual and one-off. Early in my career I spend a lot more time in debuggers. Now I go months without using a debugger.

I try not to get into situations where I need a debugger, but when that happens, having a debugger makes a huge difference compared to using print.

Re: JavaScript debuggers are broken

#103

Post by curioussavage »

teambayleaf wrote: post #66
goto11 wrote: post #39

Earlier quoted context omitted.

It is much more efficient to place a breakpoint at the spot where you would have put the print statement and then inspect the values of interest in the debugger. It is a rather false dichotomy to assume that using better tools precludes you from "careful thought".

A debugger is very useful when you trace a piece of code that 1) you understand well and 2) executes relatively linearly. JavaScript is pretty terrible at both. First of all, most JavaScript apps are just a small chunk of code that sit on frontend frameworks (React etc). This means that using a debugger, you mostly step through framework's internal code base, of which you have a vague understanding at best. Also, an…

What? It jumps around because it’s running in an event loop. Not because JS devs try to do too many clever things. You hope it jumps around often or you might be blocking the loop for too long.

Re: JavaScript debuggers are broken

#104

Post by Jasper_ »

Sawamara wrote: post #57

Some of the comments here are surreal, I tell you. Surreal. I use chrome's built-in debugger to debug compiled down typescript code. I go to the original TS files, mark a line by conditional breakpoints, it works perfectly. It stops the execution of the compiled JS files, it uses the source map to find the original line (which I placed the breakpoints in) AND it has a perfectly fine, working stack trace as well at pa…

I have had a similar experience... perfect debugging, breakpoints working, everything fine, up until yesterday. I think something in my stack got upgraded, and ever since, exceptions have broken callstacks. Trying to click a breakpoint takes me somewhere completely else in the sources viewer, and sometimes, exceptions don't break at all. No, I don't know why. Something broke, I still need to investigate, but it's another annoyance that reminds me of how much of my time is going to debugging and fixing platform issues.

I think the big issue is just how fragile and brittle source maps are. They feel like a joke, compared to DWARF and native debuginfo.

But who knows, maybe they'll start working again tomorrow.

Re: JavaScript debuggers are broken

#105

Post by [deleted] »

lugg wrote: post #96
flohofwoe wrote: post #49

Earlier quoted context omitted.

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 ho…

You've repeated AP's failing this isn't a workflow nor a replacement replacement debugging concept. It is a design paradigm that lessens the need for heavy weight debugging. Debugging still has its usecases. I, like others, just see it as an infrequently required tool when most systems when properly composed simply lack the complexity required to make them useful. > It's not about a "need to step through because your…

[deleted]

Re: JavaScript debuggers are broken

#106

Post by breatheoften »

I like this article -- its accurate and describes real pain points in the existing debugger experience which _do_ have technical causes that might ultimately derive from language/ecosystem design flaws.

I'm curious to see what the author's team is building. I'm quite excited to see language-level adoption of debugger features. It's unfortunate to me that debugger's are mainly bolted onto the side of language's with (at best) convention-based 'semantics' baked into the compiler/interpreter implementation. With the interface to 'debugger semantics' completely outside the code and with at most a language-level 'debugger' statement that is basically equivalent to adding a non-conditional breakpoint.

How about a language with a debugger() {} block so that the full logic for logpoints, breakpoints, conditional breakpoints can be persisted in the source rather than in inherently non-scalable ide gui -- and specified as part of the language design?

How about something like debugger() { setRewindTarget("point1") } -- for capturing a particular program state in a returnable way -- with perhaps some semantics/heuristics around the behavior of common abstractions which interface with out-of-process contexts (sockets and files) -- and/or the ability to specify what you want to happen to those kinds of resources inside the debugger {} block so that you can quickly create exactly the rewind behavior you want for a particular task.

How about more dynamic and easily queryable debugger contexts: 'break on first execution of each line in each function in project (for reading a new codebase)', 'break on first execution of code changed in last n commits', 'break on code written by author according to git blame' ...

How about features for augmenting print() based debugging. Baked the semantics needed to support a value-history inspector into the language implementation. A program should be able to describe 'debuglog(matrix as image)', 'debuglog(object as tree view)' and the _language_ should ensure the program is compatible with a debugger protocol able to communicate with an appropriate rendering context capable of displaying these in a useful way ...

Re: JavaScript debuggers are broken

#107

Post by mistersys »

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.

Hi. I'm the author of the post.

I actually agree here. As soon as I realize it's going to be non-trivial for me to trace the issue with the debugger, more and more instead of setting up complex conditional breakpoints I just step back from the computer and have a think, and white board out my current understanding of how things are working. Usually, I get an "aha!" moment pretty quickly.

However, sometimes I don't get that "aha!" moment quickly, it random issues endup taking 30 minutes to hours to trace.

What I've come to understand is that's only true because debuggers are so limited. For example, white-boarding out the problem is incredibly useful.. why can't my debugger do that for me, by presenting a number of ways to layout the program and some filters so I can just view my code as graph and watch execution slowed down? Today's debuggers even in their best form are like looking through a tiny peep hole at a picture, I can only see this tiny section... but I want to see the whole picture.

Re: JavaScript debuggers are broken

#108

Post by Sawamara »

Jasper_ wrote: post #104
Sawamara wrote: post #57

Some of the comments here are surreal, I tell you. Surreal. I use chrome's built-in debugger to debug compiled down typescript code. I go to the original TS files, mark a line by conditional breakpoints, it works perfectly. It stops the execution of the compiled JS files, it uses the source map to find the original line (which I placed the breakpoints in) AND it has a perfectly fine, working stack trace as well at pa…

I have had a similar experience... perfect debugging, breakpoints working, everything fine, up until yesterday. I think something in my stack got upgraded, and ever since, exceptions have broken callstacks. Trying to click a breakpoint takes me somewhere completely else in the sources viewer, and sometimes, exceptions don't break at all. No, I don't know why. Something broke, I still need to investigate, but it's ano…

That is frustrating, I concede on that point. (If there is one thing that is bad about the JS ecosystem, its the brittleness and complexities of setting up build tools. If you get together one that suits your need, you do not look at it again unless an update breaks it. Then the process of looking it up how exactly it works comes again, and this repeats yearly :P)

Re: JavaScript debuggers are broken

#109

Post by patrec »

tonyarkles wrote: post #94
patrec wrote: post #73

Earlier quoted context omitted.

What would they know? This was written twenty years ago, and as far as I'm aware neither of them had any relevant experience with languages that allow for debugger-driven development, production quality selective tracing or anything of any sophistication. A lot of programming these days involves sending and interrogating complex data via awkward and ill-documented APIs and no amount of abstract a-priori thought or ju…

Sounds like you could benefit from a REPL! Edit: > awkward and ill-documented APIs As someone else mentioned, that sounds more like a work environment problem. If using a debugger allows crap like that to persist, maybe it's better for everyone if we tone down how much we use debuggers.

> As someone else mentioned, that sounds more like a work environment problem.

Have you ever used any API by, say, a major cloud provider? For example biquery and google docs are both a buggy mess despite being high profile, long established products. Using libraries like pandas is an exercise in figuring out by trial and error how to get it not to corrupt your data and which of the recommended ways of doing things don't involve a 2 orders of magnitude performance defect.

I'm in fact mostly using "repl"-driven development for these types of problems, but of course it's inferior to what I mean by debugger driven, a crippled subset to be precise. The scare quotes are because most languages don't have real read-eval-print-loops either, but something less powerful.

Unfortunately to the best of my knowledge there are basically only two languages which support this: Common Lisp and Smalltalk (maybe factor or something else really fringe also does) and I haven't used either in years. What I mean by debugger-driven is that you can literally write your whole program without ever restarting it, from the debugger. By contrast python can't even properly reload a changed module definition.

Interestingly it's hard to google good explanatory links, but the point is that you can write some code, run into a problem, and fix the problem right there, in the debugger without aborting the current execution or unwinding the stack.

Common Lisp and Smalltalk both have a bunch of unique features that make this type of thing very powerful, for example some function calls another function that's not defined. In python you'd be screwed at this point and restart your program from scratch. In Common lisp you can just write the missing function, compile it and continue the current execution frame as if nothing ever happened. This is because Common Lisp, unlike any remotely popular language allows for resumable exceptions where you can continue from just before the error happened (it also has the usual stack unwinding exceptions).

Here's two examples I found :

https://www.reddit.com/r/programming/comments/65ct5j/a_pytho... https://malisper.me/debugging-lisp-part-1-recompilation/

Concerning low-overhead, selective tracing (that you can run in production without fear of bringing the system down): erlang for example has nice support for this, see e.g. https://github.com/massemanet/redbug (although again unfortunately it will be difficult to grok without any prior erlang exposure).

Re: JavaScript debuggers are broken

#110

Post by almostdeadguy »

lugg wrote: post #96
flohofwoe wrote: post #49

Earlier quoted context omitted.

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 ho…

You've repeated AP's failing this isn't a workflow nor a replacement replacement debugging concept. It is a design paradigm that lessens the need for heavy weight debugging. Debugging still has its usecases. I, like others, just see it as an infrequently required tool when most systems when properly composed simply lack the complexity required to make them useful. > It's not about a "need to step through because your…

> 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 prove properties about code, but usually w/ a much larger investment of time.

> The need for a debugger is a symptom of a sick system. I have never required a debugger on a healthy system.

I think people who say stuff like this are probably a little in denial about how many bugs they've actually written and how difficult it is to get any kind of certainty about the correctness of their code. Programmers write bugs, why are we policing the tools they use to fix them?

Post reply on HN