Hacker News Reader

Comment by Rd6n6 | Hacker News Reader

A good ide is all about auto completion and refactoring tools. The autocompletion means you don’t have to spend as much time memorizing apis, so you can focus more on simplifying your design and minimizing coupling. In something like unreal engine, the intellisense really sets ides apart. The refactoring means you can quickly and easily make large changes to make the code easier to work in. You can just work significantly faster if you have both of these things.

I don’t really use other ide features. Separate terminals are great

View on HN

I'm surprised how many of my colleagues don't use the debugging features of their IDE. Being able to step through code line by line and see all the variables states at any time and evaluate arbitrary expressions given those states seems far superior to print/console based guesstimation. However, somehow my colleagues still do great work!

Depending on which ecosystem you're working with you may be able to get those tools elsewhere. If you're working with client-side JavaScript for example, then you have multiple choices of browsers with excellent debuggers built in.

That’s still not the same as debugging within your IDE. Having to switch from the browser back to your IDE to find the files to make changes is just another context switch that slows you down. Plus, dealing with async loaded files can be a pain in the browser.

I've tried using VSCode's debugger for Javascript before. And it can be kind of nice, but ultimately on larger projects with their own build tools it can be hard to keep the sourcemaps working in such a way as to not screw up VSCode's debugger, and the gain over Firefox's built in debugger wasn't worth the effort for me to continue to maintain that config.

You can actually configure chrome to be able to edit your local files and save changes directly. Although admittedly it was a bit unreliable when I tried it.

Yeah but then you're editing code in, what is basically, notepad. Good luck finding the file you need to edit from the Chrome dev console.

Having the ability to do everything from your IDE allows you to leverage all of the tooling built into that IDE.

It's a fair sight better than notepad. You get syntax highlighting, Ctrl/Cmd-P to fuzzy search for files to open, and even things like multiple cursors. But you're right that it's not quite the same experience as a full editor. You won't get linting, type checking or autocomplete.

Ah but who will debug the debuggers.

Concurrent code is not easy to debug line by line. Logging is a good alternative.

I prefer printf debugging. a) it works everywhere, even say when the bug is only reproducible in a remote CI, or in languages that don't have good IDE support. My printf skills are top notch thanks to using it everywhere. b) the printf stuff can stay around until the next compile. I can easily vary it, put it into VCS, share it with others, etc. For IDEs such features may exist, but again I'm locked into an IDE.

Sure, in some settings the source code is not available and you still want to debug. Then I use debuggers. But outside of that I prefer printf debugging.

Note that I'm not saying that people who prefer debuggers are wrong. They probably have their reasons, as I have. Everyone should be allowed to use the method they prefer the most.

So far as I can tell from having worked with lots of people with lots of different preferences, there is basically no correlation between preferences in debugging approaches and ability/productivity.

I do however really wish the world made it easier to help turn both state introspection via interactive debugger and state introspection via printf shotgun into structured trace-level logging that could be shared and/or committed to the codebase independent of the original debugging tool used.

Yes this. Distributed tracing is making these concepts more popular but in many cases it requires manual instrumentation of every function call and state one wants to track. I would love to see more auto-instrumentation but seems this should be implemented at the interpreter or compiler level.

For large codebases, the code exploration features are priceless. Call hierarchy is an absurd productivity booster.

Using this right now to break apart a 5k line file. Being able to see the call hierarchy of all the functions allows me to move over functions with less dependencies and slowly work towards the ones that are heavily intertwined. I can see it all at a glance without having to jump from one function to another over and over.

Refactoring is where it's at for me. The ability to rename functions and variables across not just a local file, but all references in the code base is huge.

Relatedly, the ability to find all usages of a symbol and navigate between them is indispensable for me at this point.

Plenty of LSP clients to choose from for vim.

> Relatedly, the ability to find all usages of a symbol and navigate between them is indispensable for me at this point.

I don't know if people just aren't aware, but vi and emacs have been doing this since at least the 90s. This isn't some fancy feature that requires an IDE. Recently the support has improved even more through LSP.

> I don't know if people just aren't aware, but vi and emacs have been doing this since at least the 90s. This isn't some fancy feature that requires an IDE. Recently the support has improved even more through LSP.

No, rtags & friends aren't remotely comparable to an IDE which has a semantic understanding of the code, and will catch the uses without false positives.

I mean, I think they are? Sure jumping to a generic definition like getId will give you more choices, but i know which one i want. Having to push space and then 9 to get the second page and choose the one i want isn't the end of the world.

Recently LSP provides exactly what you desire anyways with context sensitive jumps.

Edit: Regardless, perhaps our difference here lies around what the minimum specification is. My reading of this thread and the post i responded to is that people think moving around in code without an IDE means closing one file, navigating to the next file and opening that one. This is patently not how it works, and what i was adressing.

> I mean, I think they are? Sure jumping to a generic definition like getId will give you more choices, but i know which one i want. Having to push space and then 9 to get the second page and choose the one i want isn't the end of the world.

I often do codebase-wide renamings. I would definitely lose a lot of time if I had to check every single instance of "getId" as you say (to give more precise figures, if I want to rename an "id" I get ~2000 matches). With my IDE I can just ctrl-shift-r and rename any symbol and it works without me having to think about it.

> Recently LSP provides exactly what you desire anyways with context sensitive jumps.

that's likely implementation issues but LSP for C++ in 2021 is definitely not as good & integrated as e.g. native clang integration for parsing.

LSP gives you exactly the same functionality though, since it's what VS Code is also using.

Whether the implementation is prone to false positives (it really shouldn't be) is up the server, not the client (e.g. vim or VS Code). The client actually doesn't have 'a semantic understanding of the code' - that's the point of it, not needing every editor to implement an understanding of every language it wants to support.

We know about them. When you start adding these scripts to vi and Emacs they're no longer in the realm of plain text editors. You can add a bunch of hacks to turn vi or Emacs into a poor mans IDE.

This is my favorite IDE feature! I don’t know how text editor folk do this

Error detection is a big one too. My code in an interpreted language wouldn’t error until this corner case hit, but my IDE tells me the issue as soon as I write it. It’s a huge boost.

Reply on news.ycombinator.com