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

111–120 of 124 posts

Re: JavaScript debuggers are broken

#111

Post by goto11 »

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…

But the actual argument Dijkstra makes against goto applies to any use of goto (and would also apply to break and continue and to multiple returns).

Re: JavaScript debuggers are broken

#112

Post by z3t4 »

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.

You can use Object's as name-spaces, it's somewhat common to use var global = {}; and then put all global variables in it. But I'm a big fan of scoped imports aka. require in Node.JS. Scoped import is like a global variable, but with the complexity of a local variable. I prefer function scope as it lets me declare variables where ever I want, but others prefer block scope, so either choose var or const and stick to it.

JavaScript was not the only contender for the browser, Microsoft tried with vbScript, and Google tried with Dart. Then there was ActionScript (flash) and Java (applets). And also ActiveX. Then there are various compile to JS languages, like CoffeeScript, yet plain old JavaScript still seem to be the most popular.

My own pain point with JavaScript is that it's getting more and more complicated. Personally I like to use the bare minimum when it comes to language features. And work with the language instead of against it, eg. I make use of null==undefined, I almost never use === unless I need to be explicit. Learn the Equality-Table! Also learn regular expressions! (but don't over-use them). Learn how to use closures, learn how to use callbacks. Then it becomes enjoyable. Bonus: Learn how to program without global variables, then use them when it's convenient. Learn how to program with only pure functions, then use impurity for convenience. Learn test-driven-development, but only write tests where they're needed. Learn how to program without an IDE (just plain text editor and command prompt), then go back to the IDE. All the great tools that exist today make you not feel the pain when writing unmaintainable code.

Re: JavaScript debuggers are broken

#113

Post by tonyarkles »

patrec wrote: post #109
tonyarkles wrote: post #94

Earlier quoted context omitted.

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

We are on the same page friend!

I’m glad to know that I’m not the only one who thinks a bunch of the cloud APIs are insane. I haven’t had to deal with any of that for about a year now, and I’m quite happy about that.

Re: Python and pandas, I haven’t used pandas, but did quite a bit of numpy/scipy/matplotlib stuff in the past. Jupyter doesn’t quite get where you’re talking about, but it does handle the “only have to repeat one step” things very well.

I only recently feel like I truly grokked the magic of the Common Lisp restart/repl/debugger stuff. Just the other day I used quicklisp to install a package, and at runtime it failed to open a C library (libsdl2-image.so or something like that). While it was paused asking what to do, I used apt to install the missing libraries and told it to retry. Boom. Program was running, and I hadn’t had to restart it even though a shared library was missing when I started it. Hacking on the little game I was fiddling with, I could C-c C-c as I added features to the game and keep playing it with the changes. Un-friggin-believable.

Edit: and yes, if I have to make a backend service these days, it’s generally in Elixir. Not quite the same as the beautiful Lisp stuff, but when your processes are expected to die all the time, it’s really easy to iterate quickly while keeping the system up. I feel like mistakes I make while writing Elixir code help make my overall system stronger.

Re: JavaScript debuggers are broken

#114

Post by fourthark »

ihuman wrote: post #83
tablethnuser wrote: post #78

I don't think the author knows the full set of features available in DevTools. Sourcemaps make the code look familiar. Blackboxing hides the framework stack. DevTools supports conditional breakpoints so in the article's example you could put a breakpoint in the onAddWidget line looking for widget.position.x < 0 or whatever. Voila. Reproduce the bug and you have a stack of your own code that you can inspect and find t…

The author is aware of source maps, and has had issues with them > To add to our list of feedback for Javascript debuggers here’s a couple more frustrations you may be familiar with: > Buggy source maps resulting from bundling and transpilation tools like Webpack and Babel that cause placing break points to be unreliable, and defined names declared undefined

In my experience source maps usually sort of work in Chrome, but don't really work very well in Firefox (which TFA mentioned).

Re: JavaScript debuggers are broken

#115

Post by _slyo »

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?

I use use a debugger fairly regularly when I'm writing tests. Debuggers are for moments of incredulity. When a test doesn't behave as I expect, I go back and look at my code. I'll look back and forth, and if I still don't see the root cause, then I'll fire go up gdb instead of adding print statements. Debugging a unit test is often way faster than recompiling.

Re: JavaScript debuggers are broken

#116

Post by patrec »

tonyarkles wrote: post #113
patrec wrote: post #109

Earlier quoted context omitted.

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

We are on the same page friend! I’m glad to know that I’m not the only one who thinks a bunch of the cloud APIs are insane. I haven’t had to deal with any of that for about a year now, and I’m quite happy about that. Re: Python and pandas, I haven’t used pandas, but did quite a bit of numpy/scipy/matplotlib stuff in the past. Jupyter doesn’t quite get where you’re talking about, but it does handle the “only have to r…

Yup, your apt-get example is a great one. It's very frustrating that the ability to do stuff like this completely died with common lisp/smalltalk . I don't see the appeal of exceptions at all if you don't have restarts (I'd rather have Either).

Re: JavaScript debuggers are broken

#117

Post by dang »

sametmax wrote: post #99
ihuman wrote: post #87

Earlier quoted context omitted.

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.

Could you please not post like you did in this thread? There's no need for nasty discussion and we don't want it here.

https://news.ycombinator.com/newsguidelines.html

Re: JavaScript debuggers are broken

#118

Post by lugg »

almostdeadguy wrote: post #110
lugg wrote: post #96

Earlier quoted context omitted.

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…

> 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 themselves pieces of code that itself can have bugs.

No, they are tests, bugs in test code are incredibly hard to produce if you are practicing test first development.

Most real bugs that make it into production are from conditional flows that are not being covered by tests.

> I think people who say stuff like this are probably a little in denial about how many bugs they've actually written

No denial, I know I've written a bug before.

> and how difficult it is to get any kind of certainty about the correctness of their code

Nope, not in denial about this either, I find it relatively easy. Maybe I just don't do a lot of rocket science or something.

> Programmers write bugs, why are we policing the tools they use to fix them?

Nobody is policing tool usage here..

Re: JavaScript debuggers are broken

#120

Post by intrasight »

danmaz74 wrote: post #102
intrasight wrote: post #58

Earlier quoted context omitted.

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.

Absolutely. But I think that years of programming has resulted in sort of an internal/mental debugger :)
Post reply on HN