Hacker News new | ask | show | jobs
by somenameforme 182 days ago
I think some of the big features of VSCode are the extensions and, equivalently, the nice debug support. I just started using VSCode about a week ago thanks to moving to a project that uses scons as its primary supported build tool, and I've learned to hate scons and love VSCode over that time. The completely manual tasks/launch/etc stuff is kind of weird at first, but then becomes amazing and far more convenient, after you get used to it. And the 'debugger' (kind of weird to frame it that way as its extension based, like everything) is amazing - extremely fast, great visualizations, and so on.

How would vim compare?
1 comments
torben-friis 182 days ago
I can't help you much, as currently I happen to use ruby at work and native debugging is enough - you can drop into an interactive console at a breaking point adding a single line, with no tooling.

Here's the chapter on debugging in the book I mentioned if you want to take a look: https://lazyvim-ambitious-devs.phillips.codes/course/chapter...

link
tsimionescu 182 days ago
> I happen to use ruby at work and native debugging is enough - you can drop into an interactive console at a breaking point adding a single line, with no tooling.

If you've only ever used this type of debugging, you should really try out a real IDE debugger once. The difference in productivity when you can use your IDE to navigate to, say, the usages of a function and then just press a keyboard shortcut to put a breakpoint on the line with that usage is immense.

Compare this to the native debug support: you have to leave the interactive debugger, move to your editor, find usages, note down the file name and line number, then go back to your interactive debugger and type a manual break command (break my_file.rb:2517 or something). All of that context switching and remembering is replaced by a single keyboard shortcut in Emacs, VS Code, or any other integrated debugger. And no, adding manual breakpoints in your source code is not simpler - what I'm describing works interactively while your code is already running, whereas a breakpoint statement requires you to restart the whole process.

link
torben-friis 182 days ago
>If you've only ever used this type of debugging, you should really try out a real IDE debugger once.

It's the opposite, I learned to program with java for android so a full IDE was my first experience. As I moved to node and then go and ruby I just gradually used it less and less as I generally 'debug' creating tests to check/reproduce behavior.

I do think I should improve my debugging, but mostly in terms of profiling. I very rarely feel the need to see a codepath run line by line.

I'm not saying my system is better or worse to be clear, I've just naturally gravitated to not using the debugger - I couldn't tell you why.

link
worksonmine 182 days ago
I have inline debugging with gdb in neovim.

<leader>+b/B: add/remove breakpoint

<leader>+n/N: step/over

... and so on.

To start it just run :termdebug. If you change the debugger to rr you can even replay.

It's a shame the language support is poor, but I'm sure they'll add DAP support eventually.

link
tsimionescu 182 days ago
This is exactly what I meant by an integrated debugger. I probably should have used the term IDE less, as that brings to mind Visual Studio or Eclipse and such - but I just meant any integrated editor+debugger, whether neovim, Emacs, or whatever else.
link