Hacker News Reader

Comment by sph | Hacker News Reader

I used to debug frequently when I coded on Win32 GUIs 20 years ago and running the debugger was as simple as pressing F5 instead of F9. Nowadays, with a multitude of languages, setups and editors, I don't even bother. Even setting up JS debugging under VSCode, which supposedly is a core feature, has always been an exercise in frustration every time I've tried it.

Rarely I run gdb when I'm debugging a particularly hairy C issue, but with any other language I don't even bother and add prints everywhere. The JS "debugger" statement is pretty useful, but it's still very awkward compared to the golden standard of Microsoft IDEs from two decades ago.

Don't blame the users, blame the tooling, editor and language developers that never cared for delivering a good debugging experience.

View on HN

It's hard to imagine that 20 years ago Delphi and Visual Basic had far superior IDEs and debugging experience running on my 100 MHz IBM PC with 512MB of RAM.

I'm not sure where the ecosystem went wrong, but it's strangely related to the web.

It went wrong, when young nice folks with fresh MBAs realized, that the point of diminishing returns for software quality can be very low. Just throw things into production and maybe catch some of the bigger foobars and let the hockey stick growth take over. Yes, you’ll loose some customers but more will come and it’s just not worth it spending time on shifting the exponent slightly to the left. Your evaluation will depend more on the exciting new features rolled out than the 3-per-cent-lower-than-predicted au growth.

Java IDEs still have the best tooling when it comes to debugging/observability, in my humble opinion so at least progress is not lost in every ecosystem.

Last time I used Eclipse, it took 8GBs of RAM. Have things changed?

In my opinion Eclipse is not as good as Jetbrains’s editors. But memory consumption is not the primary aspect to decide on that imo.

> 100 MHz IBM PC with 512MB of RAM

What kind of a strange beast was that? :)

I do remember fondly debugging in Delphi, but when using Perl and Python's debuggers I don't really miss it

I've written a few CPAN modules over the years but have never successfully used perl's interactive debugger (or, honestly, any other interactive debugger).

I do, however, know plenty of brilliant developers who can make interactive debuggers sing and respect different people preferring different approaches.

Note: If any of my perl code upsets the debugger it's because I didn't realise as a result of my preferences and I'll still consider it a bug.

This is slightly offtopic but windows 95 ran on 4mb of ram. 8mb was considered luxurious at the time. Visual Studio 6, launched in 1998, ran fine with 16mb of ram. It had almost all of the debugging features we have today, and it worked flawlessly every time.

Half a gigabyte of ram was, and still is, a gargantuan amount of memory.

win95 booted on 4MB, but nobody would call this running. 8MB was the norm for 486DX2 computers since 92. In 93 you had plenty of computers shipped standard with 16MB, for example this dell 466V https://books.google.com/books?id=XNt4ttAFAiwC&pg=PT2&dq=del... there are 10 computers in this issue being sold with 16MB. By 1995 Pentium with 16MB was standard, with 8MB relegated to bargain bin offers.

In the past you run your whole application as one piece on your machine, you could easily set a simple breakpoint and be done with it, now you have many interdependent components (microservices, 3rd party APIs), stuff running in the browser, stuff running in remote databases. It's like looking for a nail in a haystack. Even worse on production, you need to log every single call everywhere just in case you ever need to trace which random component caused that weird issue the client is complaining about.

> 100 MHz IBM PC with 512MB of RAM

That doesn't sound right. The "100 MHz" in the first half is too low for a machine from 20 years ago, and "512MB of RAM" for a modest machine of the same era is too high.

You are right, to be precise it was 1997 and I believe my 100 Mhz IBM PC was the 340 model which actually has 16 MBs of RAM. Running Windows 95/98, Visual Studio, 3D Studio Max, Photoshop, Cubase, etc.

Point still stands, you don't need 8 GBs.

JavaScript's remote debugging protocol is a total game changer. Highly recommend looking into it.

And yes you can use it on frontend stuff if you invoke your browser correctly

And yes you can use it to debug mobile through chrome's inspect feature. And yes you can proxy that to use it in your editor of choice and yes GUD with emacs is supported

And yes the "debugger" keyword correctly triggers the breakpoint through this entire pipeline. It's borderline magic

Remote debugging is not new. I was doing it with vc++ back in the early 00's, & am pretty sure was there in the 90's.

Of JavaScript? Really?

The concept of remote debugging is just one of instrumentation, that's from the 1960s, this isn't a conceptually new thing. It's a functionally useful one

The issue with JavaScript debugging is you are often using an ad hoc pipeline of transpilers. So even if you pause at a debugger Keyword, the code may look completely different. It takes work to get source maps to work correctly.

Shouldn't source maps take care of this in all but the production build

They should. They don't always do in practice, and debugging broken and useless source maps is another pain area.

One of the main reasons I always use vanilla JavaScript.

That's rather more an issue with "using an ad hoc pipeline of transpilers" than it is an issue "with JavaScript debugging".

Used to be

    ndb index.js

But node debugger died at some macos release and I haven’t figured anything close to it.

ndb definitely stills works for me on Mac. But these days, I just use VS code. Open a special JS terminal (https://imgur.com/a/nqEFYkz), then the debugger will auto-attach to any Node process run in that terminal.

IIRC it was one particular aspect, maybe it playwright or other third party tool that was crashing it.

Thing that's nice with ndb it's the same UI as Chrome devtools that I'm so used to.

Debugging via Webstorm felt too weird (tho probably 2x more powerful). Not a VSCode user.

It even works in prod: send the appropriate signal to a node process, pipe the default debug port through ssh and open your node devtools locally. This has saved me so many hours.

It's magic if:

- you set it up correctly

- your entire stack is compatible from end 2 end

- there is now weird thing with map files

- you don't dev using firefox

It's a lot of if.

Jetbrains IDEs are just as good as Visual studio. As is XCode, QT creator and friends. And they work with many languages.

I know it's a problem with Python and Node though.

Try debug a racing issue with debugger. If you use it, issue dissapears, if you don't issue it's there.

Using print is a sign tooling isn't up for the task. Not necessarily inexperience.

> Using print is a sign tooling isn't up for the task. Not necessarily inexperience.

This. For application developers, if your users aren't taking advantage of features in your software, it's a sign the features either aren't actually better, or aren't intuitive enough to gain traction. It's a tell that you still have work to do.

I don't see why the same arguments wouldn't also apply to tools for developers like debuggers. Just because your userbase is more technically savvy doesn't mean you shouldn't care about ease of use.

A print will quite often make the race issue disappear as well (due to it being synced in many cases). The JVM’s flight recorder may be a better option to fight such an issue.

Try an asynchronous logger in that case.

A debugger can work in many ways, it can also print, or trigger on altered memory. I would say that a debugger is generally more useful for finding race conditions than logging. But writing tests is really the best tool there.

In my opinion printing or logging is much more useful than debugging when you want to be able to understand the sequence of events leading up to a bug, where the debugger isn't very strong. After analyzing the logs, using conditional breakpoints depending on each other can help you catch the issue live.

Each tool has their strength and weakness, but I would never go so far as to say that debuggers are pointless. Being able to inspect memory and browse for inconsistencies can be priceless.

> Jetbrains IDEs are just as good as Visual studio. As is XCode, QT creator and friends. And they work with many languages.

Do these support edit and continue?

Last I played with XCode, it didn't.

Major flaw.

Jetbrains - yep.

Both edit variable and hot reload code.

A common thing I do is find the problematic code using the IntelliJ debugger, change the code, press Cmd+F9 to reload the function code, hit "drop frame" so the executing code goes back to the previous function in the stack (the caller function) so the edited function can execute again with the new code.

While at it, you can also change the value of any visible variable and evaluate any expression in the context of the currently executing scope.

Python and Node both let you debug with breakpoints and inspections and what not, if you're in IntelliJ. Though far inferior to their Java support, of course. Both in terms of the actual debugging experience and in getting it to run as such.

But if you’re working with Python shouldn’t you be using PyCharm? (No idea, I don’t use either )

Language-specific JetBrains products are just IntelliJ with the language-specific plugin. Said plugin can be installed in IntelliJ directly.

Oh I had no idea :) thanks for explaining.

Yeah, I was just saying IntelliJ as a general catch-all. I'm mostly a Java developer, but I (mostly) seemlessly add other languages to my workspace.

I debugged Python under VS Coded just fine until the point when it became unbearably slow as the script grew.

I debugged Python code in Emacs just fine. It is much less useful than logs for the work I do but it has its moments.

In Python the IDE doesn't matter as much, because if the support is bad, you can always fall back on pdb.

In fact, I often use pdb anyway because it is sometime just quicker to run, and the code execute faster under it. Also, being able to execute any python code in a shell like env is super nice, and the concept of having commands instead of looking for a button has the same pros/cons than the cli.

PyCharm can debug Python code no problem, everything works out of the box.

JetBrains, XCode and VisualStudio just don't work on anything but the latest most expensive computers.

I too got spoiled by Visual C++’s debugger.

Nothing on other platforms combines the power and ease of use.

Visual C++'s debugger is so good that it changed how I wrote code. It let me debug things that I couldn't debug with a lesser tool.

That's why I quit using it and went back to debugging with print.

Print-debugging limits my cleverness and forces me to think about what's going on.

Debugging C# in Visual Studio is at least as good.

Visual Studio is plainly the best IDE I've ever worked in. It may be sluggish at times, but whether I was coding in C#, C++ or Python, autocompletion, debugging, and refactoring always worked really well.

The only problem is my current projects are all on Linux.

My current role is mostly done by Windows people (my direct boss is a Windows guy, although his boss runs Linux at work) and I took it while interactions were minimised due to COVID so we decided I should run Windows on the work laptop.

So I figured "When in Rome" and I have Visual Studio and I expected I would come away saying this is pretty cool but I want a modal editor.

Nope, it's terrible. It does have a debugger that is better than I'm used to, but I spend very little time in a debugger, what we're doing isn't rocket surgery. Visual Studio apparently doesn't understand how git works or doesn't understand how files work, so e.g. I'll modify somefile.cs in one tab to fix something, compile, verify my fix worked, go to the Git tab and Visual Studio is wide-eyed. What could I want? There aren't any changes. Yes there are VS, you just saved them, to a file.

So I exit VS and restart it. "Oh!" realises Visual Studio, somebody changed the file. Yes, it was you. You wrote to the file, when I hit save. That's what files are Visual Studio, why is this hard? Now I can commit my change.

C# is a much better language than I expected, PowerShell is a much worse language than I expected. Lots of surprises, good and bad, but I think "Visual Studio is bad at the thing it's for" was the largest surprise.

Try Jetbrains Rider. It's miles ahead of VS, but don't expect a miracle.

Just because you're using an IDE doesn't mean you can't use a second tool simultaneously.

It sounds like using a second program to add and commit files to git would work better for you.

(I've not spent much time with visual studio)

Yeah, I use Visual Studio for code editing and TortoiseGit for GIT related stuff (checkin/pull/push)

Can't really comment on git functionality, I've always used the CLI for that.

> what we're doing isn't rocket surgery

Nor brain science either, I'd hazard.

Well, the University where I work (used to?) employ the founder of BBS:

https://www.cambridge.org/core/journals/behavioral-and-brain...

Although that's mostly because BBS was ahead of its time rather than because of the topic specifically. BBS looks a lot more like how you'd design such a thing if you started out in an era with the Web, rather than dusty printed journals, even though BBS actually is a printed journal and started in 1978.

Anyway, Stevan Harnad actually taught a class I took (as a postgrad, so not pass-or-fail, I was just showing up because it was interesting). Cognitive Science is definitely Brain Science, but it's true that I am not employed to actually do that.

Strong disagree, I use Visual Studio daily, and git integration works great in 2022.

It used to suck not unlike you describe and there is a slight hidden gotcha - you need to select git as your source code provider in the settings as VS supports other version control systems as well.

VS is great for .NET dev, but stay far far far away from its git integration. It’s always sucked. Even if JetBrain’s git tooling is infinitely better, personally I still prefer using the command line because I don’t trust a UI to do the right thing with respect to git.

I use IDEs extensively but never the part where it integrates with the git. This is where the command line / specialized git frontend suite me just fine.

Have you considered using another editor and debug with WinDBG? Same debugging engine as Visual Studio but with a command line.

I don't disagree, but borland c++ and turbo pascal both had excellent debuggers, the latter is still working under the guise of lazarus (but i'm not a fan of the gui). What spoiled me in vc++ was remote debugging, statement completion & type/object browsers.

I worked both in Visual C++ and in phpStorm+XDebug and I liked the latter more.

For MSVC, I had to write some visualization files (.natvis), phpStorm displays everything just fine.

Dropping in a import pdb; pdb.set_trace() in my pytests and running them from the terminal has helped me squash some pretty difficult bugs. It’s dead simple (same with Ruby pry)

Since python3.8 you can just call `breakpoint()` and it does the same as `import pdb; pdb.set_trace()`

Also since were on the topic I started using pdb++ and my debugging got incredibly more efficient.

https://github.com/pdbpp/pdbpp

Nice recs, I’ll have to check pdb++ out. Another tip is to add —-pdb to pytest so that it starts the debugger on each test failure.

You should check out ipdb too. That’s my recommendation.

I like ipdb over pdb. All of the niceties of ipython when debugging. If you export `PYTHONBREAKPOINT=ipdb.set_trace` you can use this ipdb too.

I also wanna give a shout out to pudb, for those who want a more visual experience. It uses curses to offer a GUI-like debugging experience while on the terminal. Real nice piece of software.

I do this all the time! I also do this when writing code, like if I'm getting some json blob from an API call, and I'm not quite sure what it is...

Can you attach pdb to a running python process these days?

That’s a good question and would be interested if anyone knows the answer. I used do this a lot with gdb and C++ server code

Now that I think about it I bet you could attach pdb to a process running the python interpreter and find your way to the right level of abstraction. Does not sound practical though

PDB is rubbish compared to Debugpy. You should try that instead. With VSCode you get a proper GUI debugging experience.

I’ll check it out. In my current environment I optimize for simplicity and ease of setup, so that means vim + pdb. But that could change in future.

I've found vscodes js debugging to be really straightforward. You open a their terminal, place some breakpoints, then run any command you want.

Yes, half the blame is on the languages

I wish there was a 'here be dragons' statement that you could put and it would run a function or a snippet on a special debugging mode (without the need for a debugging tool). And then ask questions like "who set this to value X" or "just print the local vars here" etc

I think the closest we have to this are the debugging environments that (for example) Flask gives you (maybe other frameworks)

That's basically how breakpoints work in python, right ?

There's a stack frame and you can watch on variables to trigger the debugger when they change.

But there's no operation tracing. I'm not aware of any language/system that automatically logs all operations with their context/value and boils that down to a useful display.

Debuggers seem to all use the ancient machine code model where they replace an instruction with "And now launch the debugger to see what state the variables, memory, and registers are."

It would be useful to have more print-like features that create a searchable list of all entries/exits/creators/destructors in sequence with associated parameters and values.

There are even time traveling debuggers that can reverse code flow, so I’m sure something similar exists.

It's a casualty of the orgy of complexity we've indulged in for the last 15 years. You're absolutely right, we had all this stuff 20 years ago.

Thirty+, I stepped through code in char mode DOS.

Anyone frustrated with debuggers, check out RemedyBG https://remedybg.itch.io/remedybg

Insanely fast and capable debugger for Windows. https://www.youtube.com/watch?v=r9eQth4Q5jg

(I have no relation to the project, just think it's great)

JS debugger was amazing a few years ago. I find it struggles with the transpilation and functional elements of debugging something like a Typescript React app with multiple hooks and async operations. Stepping through the code and setting breakpoints doesn't work as expected in some cases and I revert to just slapping console.logs() everywhere to trace execution.

Connecting the chrome debugger to a nodejs backend is pure luxury. I think it could compete with the M$ experience easily.

My current pain point trying to get python debugging working on vscode remote with containers.

So sadly, lots of print(f"")'s

It’s still exactly the same in Visual Studio today for .NET or C or C++. Super easy to do.

At least Go debugging in Jetbrains' Goland is a smooth and effective experience, on the other hand. I think their other language IDEs are more or less on par.

> Don't blame the users, blame the tooling, editor and language developers that never cared for delivering a good debugging experience.

Do blame the users. If they would've said "nah, I'm not using your programming language, it doesn't have a decent IDE and debugger", life would be much better.

I have a feeling no programming language would ever be used anywhere if we were just as strict with other aspects besides "having decent IDE and debugger"

Name one thing an IDE can do that I can't do with my (Turing complete) editor and shell.

An IDE can let another programmer learn the project without you being there to explain the details of your bespoke tooling.

My bespoke tooling does not require anyone else to use it to navigate or learn any project unlike some IDEs which is the biggest problem with them.

Reply on news.ycombinator.com