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

91–100 of 124 posts

Re: JavaScript debuggers are broken

#91

Post by haburka »

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 love typescript. I use it basically as much as I can. Some projects have builds that break breakpoint support. I’m not sure of the exact cause, but it is frustrating. I often have to disable source maps when this happens,

Re: JavaScript debuggers are broken

#92

Post by seanmcdirmid »

woah wrote: post #89
tonyarkles wrote: post #88

Earlier quoted context omitted.

> GDB of course Every time I end up using a GUI debugger, I end up disappointed. GDB has spoiled me. Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. A recent example: I have a state machine on an embedded system that is somewhat timing dependent (delaying a couple milliseconds is fine, delaying >1 sec is not). I stuck a breakpoint on the entry point and told GDB to dump…

You could just write that code temporarily inline

Ya, that’s what I would do. More to the point, the interface for more more advanced debugger features generally don’t make them worth it (eg intellitrace). Debugging is a heavily constrained usability experience.

Re: JavaScript debuggers are broken

#93

Post by Bjartr »

tonyarkles wrote: post #88
seanmcdirmid wrote: post #84

Earlier quoted context omitted.

It is bad compared to more developed debugging experiences (Eg visual studio and C# or even eclipse and Java). It is better than nothing or GDB of course. I personally think the Chrome debugger interface is horrible, but that is easily fixed by using Visual Studio Code instead. Even then, things feel off...but more like unpolished.

> GDB of course Every time I end up using a GUI debugger, I end up disappointed. GDB has spoiled me. Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. A recent example: I have a state machine on an embedded system that is somewhat timing dependent (delaying a couple milliseconds is fine, delaying >1 sec is not). I stuck a breakpoint on the entry point and told GDB to dump…

> Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit.

Conditional breakpoints in chrome could do this for a while by having your conditional be a call to a logging function, and it was recently made more discoverable and user-friendly as "logpoints".

Re: JavaScript debuggers are broken

#94

Post by tonyarkles »

patrec wrote: post #73
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.

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.

Re: JavaScript debuggers are broken

#95

Post by tonyarkles »

woah wrote: post #89
tonyarkles wrote: post #88

Earlier quoted context omitted.

> GDB of course Every time I end up using a GUI debugger, I end up disappointed. GDB has spoiled me. Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. A recent example: I have a state machine on an embedded system that is somewhat timing dependent (delaying a couple milliseconds is fine, delaying >1 sec is not). I stuck a breakpoint on the entry point and told GDB to dump…

You could just write that code temporarily inline

Sure, if I had access to some kind of console output interface! I could have set up a UART, and a bunch of complex code to walk through the whole data structure, and hoped that formatting and streaming it all out didn't blow my timing.

Or I could do:

    break fsm_entry
    command
    p/x event
    p/x state
    c
    end

Re: JavaScript debuggers are broken

#96

Post by lugg »

flohofwoe wrote: post #49
lugg wrote: post #48

Earlier quoted context omitted.

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 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 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.

Debuggers are for debugging. Not development.

It's not a rule without excception but in the general sense 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.

Like what are you validating that your tests aren't? Why aren't your tests validating it?

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

I've used them on healthy systems for more complex problem sets but by and large I only reach for them when someone has done something appalling.

Re: JavaScript debuggers are broken

#97

Post by wwweston »

sametmax wrote: post #86
ihuman wrote: post #82

Earlier quoted context omitted.

There's no need to be snarky towards the person you are replying to. Just because you don't like using plain Javascript, that doesn't mean others aren't allowed to, or that their feelings are worth less than yours.

If somebody comes to a DIY expert forum and says it's a joy to use a rusty screw driver to hit a nail just because that's the only thing in his toolbox, that person is bound to get a few snarky comments.

A more apt metaphor might be hand tools vs power tools, in case you someday arrive at a place where you're actually trying to explore the point, but I suppose the intentionally stacked metaphor choice is a convenient signal to onlookers.

Re: JavaScript debuggers are broken

#98

Post by rndgermandude »

flohofwoe wrote: post #70
rndgermandude wrote: post #61

Earlier quoted context omitted.

Sure, blindly accepting what famous people say is problematic. But then again, Kernighan, Pike and Dijkstra became famous because of merit and not because of whatever made Kim Kardashian famous. So it seems reasonable to at least entertain the ideas people like them put forward, instead of dismissing the ideas outright, or dismissing the idea after only the most superficial thinking. Dijkstra make an argument that pr…

Sorry for moving the discussion a little bit off-topic, but I like the "Goto considered harmful" as example of cargo-culting, because Dijkstra wrote this when structured-programming wasn't common, and a goto at that time literally meant "jump anywhere in the entire program", like GOTO works in BASIC. Meanwhile, goto has been tamed and has become a part of the structured-programming-toolset. In C you cannot jump out o…

Well, even today it's not entirely useless as a mantra: I have seen a lot of "hardware" and "signals" people in university who when they first had to do something in C or C++ used goto instead of loops and if blocks, coming from an assembler mindset probably where you have to (conditionally) jump (aka goto) around. I had people come to me and ask me "how do you do goto in java" in a java class where I was kinda a TA-A. "Goto considered harmful* (*most of the time, in higher level languages)" still served as a good enough rule of thumb.

Re: JavaScript debuggers are broken

#99

Post by sametmax »

ihuman wrote: post #87
sametmax wrote: post #86

Earlier quoted context omitted.

If somebody comes to a DIY expert forum and says it's a joy to use a rusty screw driver to hit a nail just because that's the only thing in his toolbox, that person is bound to get a few snarky comments.

This isn’t that hypothetical forum. Here, just because someone has a controversial option, that doesn’t mean your allowed to be snarky towards them. https://news.ycombinator.com/newsguidelines.html > Be civil. Don't say things you wouldn't say face-to-face. Don't be snarky.

I would say it face to face.

Re: JavaScript debuggers are broken

#100

Post by lispm »

saagarjha wrote: post #4

An interesting trend I've seen is that interpreted languages often lack a debugger, as most "prototyping" ends up happening in a REPL, which act as sort of an interactive debugger with each prompt serving as a sort of "barrier" where each value is guaranteed to be reified and execution is not in some awkward place. Whereas with compiled languages you have debuggers that "work" because there's a consistent model of ho…

In Lisp usually a debugger is built into the REPL.
Post reply on HN