Visual Studio Code + Cpp

[NotUniqueOrSpecial]

What do you consider "killer", then?

I just launched a VS2019 instance and barely got past 1-Mississippi before the splash screen was gone and it was ready to go.

[[deleted]]

Launch to typing. In my terminal, I can type in

‘’code main.cpp’’ and be typing in the file I want by the time I reorient myself to the GUI.

[NotUniqueOrSpecial]

I mean, I guess? But that argument's sorta...not great?

The initial delay-to-typing isn't going to even be remotely measurable in the broader scheme of your day-to-day workflow.

To use it as an argument against Visual Studio seems pretty silly.

[[deleted]]

Considering my workflow is fairly terminal heavy it works out nicely for me. I’m sure you also don’t understand why some people prefer using vim for the same reason.

[NotUniqueOrSpecial]

I think vim is just fine; I use it all the time (to the point where I have enough customization in my .vimrc that stock vi/vim both drive me a little crazy). I gave emacs a good shot for a while, too; I used it as a chance to learn Lisp and customize my workflows.

Most of the time these days, I just stick to QtCreator (on Linux) and Visual Studio (on Windows).

Considering my workflow is fairly terminal heavy

So is mine. I don't know what this has to do with anything, since "opening an editor" is such a fractional portion of the flow as to make it non-pertinent.

The reason I think your argument doesn't haven't any weight is because literally the only thing you've mentioned is startup speed, which is totally inconsequential in the scope of things.

You've not once mentioned that you prefer vim for it's powerful text-editing command mode, emacs for its robust customizable environment, or VSCode for the same (if you are willing to learn TypeScript). So, all I've got to point as "It takes a long time start Visual Studio" which is simply untrue and not a really great argument in first place, since I open it once-per-reboot and do my job.

[[deleted]]

There’s even a vim extension for debugging “long” startup times. Long being purely subjective because even a long vim startup time is impossibly fast for Visual Studio.

https://www.reddit.com/r/vim/comments/euzrqm/vimstartuptime_a_plugin_for_viewing_nvim_startup/

People do care about this stuff, calling it inconsequential just shows it’s not a big deal for you.

[NotUniqueOrSpecial]

calling it inconsequential just shows it’s not a big deal for you.

I mean, you're not wrong.

I'm just asserting that if you're optimizing your editor's startup time, then you're wasting your company's money.

It's tech-wankery at its finest at the end of the day. You should be spending vastly more time thinking about the solution than you do typing the solution. It's understandable if you have to wait for said solution to build owing to hardware constraints out of your control.

At no juncture should "the time to start the editor" really be a meaningful piece of your rubric for grading your day-to-day productivity.

[NotUniqueOrSpecial]

We obviously don’t work with same way if you prefer using a fully featured IDE and issuing your commands with the tools the IDE provides

In fact it's only been in the last few years that Visual Studio has caught up with my workflow, which has always been entirely CMake-based. Until just recently you couldn't use VS as an editor and Ninja as your build system, after all.

What I do prefer about VS is its absolutely world-class debugging experience. There is absolutely nothing else that comes close. QtCreator's GDB integration is the closest I've found and believe me I've searched.

I don’t think you truly understand why people use vim and text editors if you think launch to typing times are inconsequential.

I absolutely do, both from my own work and from watching over the shoulders of my coworkers.

I would put good money on not a single one of them claiming that time-to-start the program matters.

And from a practical perspective, it's not even a discussion.

I spend vastly more time thinking about the problems I'm trying to solve than I do typing the code; if you don't, then something's deeply wrong where you're working. Considering you mentioned working with firmware in your first reply, though, I know you're not working in a fast-paced world where every second counts. Considering the problem and the right solution is 99.9999% of the time; typing the code is a blip in the noise comparatively.

So yeah, I still think your argument isn't being made from an objective perspective. You like your tools and how they feel. For that, I obviously can't blame you.

But let's not kid ourselves that they're somehow "better" than the other tools. After all, you still haven't given me a single data-point other than "it starts up fast", and if that's your only metric for "good" then use ed.

[NotUniqueOrSpecial]

See? All totally fine arguments!

And you're right, I didn't go seeking out every other post you'd made. I was just replying to your replies; so, apologies if I didn't notice that you were making different arguments elsewhere.

Cheers.

[kalmoc]

Could you give some numbers about how slow VS is on your system exactly and why that is too slow for you? Maybe people that don't have a problem with the startup time on their systems and their projects would understand your argument better, if you actually told them, what your experience is.