Live data from Hacker News

Benefits of Not Using an IDE

alexander-hansen.dev

251–260 of 389 posts

Re: Benefits of Not Using an IDE

#251
post #4

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

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!

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.

Re: Benefits of Not Using an IDE

#252

Earlier quoted context omitted.

The best developers I've found are the ones who know how to work without an IDE, even if their preference is to use one. Contrastingly, the worst, slowest developers I've worked with rely on their IDE without understanding what it's doing for them, and are helpless in new/unsupported situations. They also, 100% of the time, screw up their git repositories on a regular basis, and need someone who knows what they're do…

But you don't use git to write your code. Code autocompletion and cross referencing are pretty big productivity boosters that won't prevent you from learning command line git. Also I bet you don't use the command line for diffing files. Also the problems is that most IDEs half ass their git client. When I was using Sourcetree, I rarely ever felt the need to go to the command line.

> Also I bet you don't use the command line for diffing files.

Wait, isn't this normal? I run "diff" and "git diff" all the time (I think I have those both set up to invoke colordiff, but it's still a command line program). Also vim -d.

Occasionally I browse diffs on Github or Bitbucket instead. I don't find it an improvement. I do favour editors over IDEs, but I don't think I'm an extremist on this one.

Re: Benefits of Not Using an IDE

#253

Earlier quoted context omitted.

> The best developers I've found are the ones who know how to work without an IDE, even if their preference is to use one. The best swimmers can stay afloat with pounds and pounds of weight dragging the down; the worst swimmers will drown. Doesn't mean weighing you down makes you a better swimmer.

Ironically, it would make you a better swimmer - it will help you build up strength, stamina, and technique. An excellent choice in analogies.

I mean, assuming you don't drown.

Re: Benefits of Not Using an IDE

#254
post #57

Earlier quoted context omitted.

What about refactoring tools? What about integrated debugging, stepping right into the code you're editing on your screen? What about hot reload? If Unixheads would stop pretending their stone-knives-and-bearskins development tools were equivalent to full-fledged IDEs, development would have advanced much more than it has decades ago.

> What about refactoring tools? The old unix editors have had rename across project, find references, go to definition/implementation for several years at this point via lsps (the same way vscode gets its functionality). > What about integrated debugging Those are usually (slightly ecosystem dependent) wrappers around a terminal debugger. > What about hot reload? Correct me if I'm wrong, but these are also wrappers a…

>>What about integrated debugging

>Those are usually (slightly ecosystem dependent) wrappers around a terminal debugger.

And, in my experience, are vastly more convenient than terminal debuggers alone.

Re: Benefits of Not Using an IDE

#255
post #204

Earlier quoted context omitted.

Why do doctors memorize medicines and their effects? Because it's faster to retrieve from memory than from documentation, even automatically presented documentation. It removes a context switch. The "brain cycles" are only run while doing the memorization, not while actually doing the work. > I don't recall ever struggling to remember syntax of languages I frequently code in. Because you've memorized it.

Do they have every single medicine memorized, or just the ones they most commonly use? Sure, I tend to remember the parts of libraries and apis I use often, but I'd still argue my editor having a reminder just a keystroke away is very beneficial.

Reality: They rely on medical representatives to know what the actual medicines are. They remember the ones with the most kickbacks.

Re: Benefits of Not Using an IDE

#256
post #30

Earlier quoted context omitted.

vim-fugitive is also a great way to interact with git since you use vim.

magit for the emacs folk

Truly one of the best new things in emacs in some time. Even better than org mode. Tho I still use command line for check ins and pushes, old habits.

Re: Benefits of Not Using an IDE

#257
post #57

Earlier quoted context omitted.

What about refactoring tools? What about integrated debugging, stepping right into the code you're editing on your screen? What about hot reload? If Unixheads would stop pretending their stone-knives-and-bearskins development tools were equivalent to full-fledged IDEs, development would have advanced much more than it has decades ago.

I use both, one method is just less restrictive.

The whole "real men use vi" type superiority complex failure mode is intensely annoying (and I say this as somebody who often has original ex-vi installed) but the inverted version where you just have a superiority complex from the opposite direction isn't actually any better.

It continues to amaze me that "it's worth becoming familiar with a wide range of tools and then pick the one that's going to work best for you in any given situation" is a concept so many people have trouble with.

Re: Benefits of Not Using an IDE

#258
post #65

Earlier quoted context omitted.

> they could pedal the same amount and go faster Nitpicking, but in the world of regulations, electric assist tapers off until around 25-30 km/h, at which point you start carrying the entire bike anyway, plus the dead weight of the battery and the motor. I wonder if this simile could be extended to programming. Being hindered by not being able to choose your own tools?

In the US, class 3 electric bicycles can assist up to 28 miles per hour, or around 45 km/h. I might be able to ride 28 miles per hour on a regular bicycle, but I can't do it for very long.

Are they regulated like non-electric bikes? In Europe, I believe the main difference is insurance and license, which are required for e-bikes with motor-supported speeds > 25km/h (at least in some countries, not sure how uniform it's handled).

Re: Benefits of Not Using an IDE

#259
post #106

Earlier quoted context omitted.

I find that spinning up QtCreator on a new machine is orders of magnitude faster than transporting a vim configuration.

1. Optional: do install of neovim 2. git pull dotfiles 3. cd dotfiles 4. install.sh 5. Profit $$$ Sure, there's some initial setup time but I'm not seeing how its orders of magnitude faster unless your vim config is super bloated and/or has a lot of external dependencies.

Yeah. For my vim I need fd, fzf and rg. So my dotfiles repo also has an install script. I never had the patience to setup lsp correctly. Maybe I’ll try again with all lua neovim plug-ins and config.

Re: Benefits of Not Using an IDE

#260

None of these feel particularly true to me, but in particular "less code is more readable" is just so clearly not true. If this was the case we'd all still be using Perl.

I see some truth to this, under a more reasonable interpretation. Clearly, well-golfed k/j/q/apl isn't doing the reader any favors. On the other hand, unnecessarily verbose code can be just as tortuous as unnecessarily terse code. And when you're comparing apples to apples (e.g. same algorithm, same data structures), shorter code is somewhat correlated to better performance.

In terms of developer productivity, less code faster to write and faster to read. To a point. The sweet spot is the shortest code that's still easy to read & write.

Post reply on HN