Hacker News Reader

Comment by kangaroopouch | Hacker News Reader

> But are there any other reasons, technical or otherwise, why people don't seem to use VSCode for things beyond editing code?

The best answer I've seen to this question is https://www.murilopereira.com/the-values-of-emacs-the-neovim...

Amongst other things, it lists different values that each tool prioritizes, and how "Core values are self-reinforcing. They attract like-minded people, who will then defend them."

Emacs: Extensibility, Freedom, Introspectability, Keyboard centrism, Stability, Text centrism.

VSCode: Approachability, Integration, Maintainability, Progressiveness, Velocity.

That is, even if VS Code achieves technical parity with Emacs (wrt introspectibility/extensibility), its community might not prioritize using VS Code for things beyond editing code.

Or maybe it will. These things are difficult to predict!

View on HN

I started out with VSCode hoping it would be an easier, more modern Emacs. Calva was the closest thing to a good experience I could get. Now I am switching to Emacs for CIDER and generally the Emacs ecosystem.

I doubt I'll ever not use vim when I'm working/thinking in systems mode, though. The thought of waiting for a "real" editor to launch when I just want to edit a tiny unstructured file is a sad one to me.

If you're interested in a reliably-quick-to-start editor, and prefer the Emacs ecosystem, consider https://www.gnu.org/software/zile/ . It's built for that purpose.

I used to use a light editor for quick edits, jed, but now I use Emacs too. It turns out that Emacs in text mode without a full configuration (so: "emacs -Q -nw") starts nearly instantly on a few years old laptop, so I just aliased jed to this command. It's about ~110ms for start+exit, good enough for me. And all of Emacs is there, even my init if needed.

> The thought of waiting for a "real" editor to launch when I just want to edit a tiny unstructured file is a sad one to me.

Amen to that. That's why I use emacs. ;) Just timed it myself, started and ready to go in 120ms. Pretty sure we can shave more time off that.

>>Just timed it myself, started and ready to go in 120ms.

Let me get this straight. You plan to code for hours, and your biggest concern at this point in time is your editor takes 1 - 2 seconds more to start?

A second is 1.666666666667% of a minute. And 0.02777777777% of an hour. Just how much more productive are you getting by saving this time?

On the other hand emacs is notorious for making users spend days to get a decent working set up. And even that's more like bad vscode clone than anything else.

Programmer brains are weird, and are stimulated thoroughly by any and all optimization, especially ones that are impossible to not see

On the scale of reality, it's obviously less time to just pick up VScode in a few hours of learning (if that), and then deal with it taking 2-3 seconds to launch

But on the scale of programmer brain, it's clearly wayyyy better to invest days into learning emacs, writing custom configs for it, learning plugin ecosystems, and the like so that you can see and FEEL that 150ms startup every time.

That's ok if all you write is something like C or C++.

If you are writing html, css, react, js, python, sql and myriad other things. Then having all of this configured to your likings is a multi month project. While vscode gets you up and running in minutes.

Edit efficiency should be least of your worries. vscode constantly reminds me if I forgot to import something, or if I imported something and forgot to use it. It lets me navigate code semantically, not just through text tags. It lets me debug, have a project running on a remote box, and let me work on it like Im working locally etc etc. Writing a full feature list will make this a blog post/book.

At the end of the day my job is write code, not to work on side tooling projects.

> Let me get this straight. You plan to code for hours, and your biggest concern at this point in time is your editor takes 1 - 2 seconds more to start?

NO. Mine isn't. I happily used emacs when it took a solid half a minute to fully load. Hell, I once was stuck on an AIX machine that needed lots of maintenance and figured it would "save time in the long run" if I built emacs from source so I could debug things there instead of copying files back and forth. Eight megs and constantly swapping and I feel fine. :) I was just pointing out the startup time as an easy way to pop the nonsensical argument that on today's hardware emacs is anything but lightning fast.

> On the other hand emacs is notorious for making users spend days to get a decent working set up.

Days? Powerful tools can take years to master! The best are those which let you be productive immediately, while providing a natural and built-in path for you to grow as you need to. Make easy things easy, hard things possible, &c.

> Just how much more productive

It's naive to measure productivity in editor startup times when developer satisfaction is way more important.

Clearly this developer values shaving time off editor start time. Seems like it's a mistake to conclude they are concerned about recouping the milliseconds.

>>It's naive to measure productivity in editor startup times when developer satisfaction is way more important.

To be honest, I don't even notice what happens in 1 - 2 seconds.

Its like less than the time I take to sip my green tea.

And yeah more importantly. I don't kill vscode and restart it every day that's more like once in a few weeks.

I think Im ok sacrificing 1 - 2 seconds a month for the value vscode has to offer.

This is a great point, however the number of users of VSCode is so high (71% of StackOverflow users in 2021 [0]) that it's unlikely that it's only attracting users with a certain set of values.

[0]: https://insights.stackoverflow.com/survey/2021#section-most-...

> Velocity

Hmm not so sure about that. The main reason that I have not complete switched over to VS Code, is that it feel klunky and I'm using a 16GB macbook pro, not top of the line, but something where I should expect a code editor would feel not so klunky.

In the context of the linked article "velocity" is defined to be "Short and focused release cycles, aligned personpower, leveraging the community effectively". I think VS Code exhibits this value.

Let me correct you on one thing:

> VSCode: Approachability, Integration, Maintainability, Progressiveness, Velocity.

VSCode: Microsoft, Approachability, ~Integration~, ~Maintainability~, ~Progressiveness~, ~Velocity~.

Hey, thanks for the link, it was a really nice read!

Reply on news.ycombinator.com