Comment by robenkleene | Hacker News Reader

Comment by robenkleene | Hacker News Reader

Responding to one of Carmack's follow-up tweets (https://twitter.com/ID_AA_Carmack/status/1302652989610618882):

> Yes, it can be very impressive watching people using the power tools to maximum advantage, and sometimes is can be a dramatic win, but I usually think that it adds up to... a few minutes saved a day?

I think measuring the gains of text editing features in terms of time is a distraction. Expressive editing features take something tedious and make it effortless. It makes it easy to do something that I'd normally put off.

But the reason text editing features end up not being that important is that if the task is mission critical, you'll end up just soldiering through, even if it's tedious. Therefore it's an incremental benefit not a revolutionary one.

I like text editing features because I personally like being organized, not because I feel like it makes me a more effective programmer. It lets me indulge myself in keeping code organized without that becoming a time sink.

This is very similar to how I look at it. Expressive editing features do not have a direct impact on my productivity when coding.

However, for those 1-2 hour focused coding sessions, it is easer for me to enter and stay in flow when I feel a better connection to my tools. Since I do perhaps a dozen of those a week, I am able to accomplish more and do it more enjoyably, even if I only spend 20% of my work time in one of those sessions.

I am not sure exactly how much the productivity increase is because I haven't tested it rigorously (honestly not sure how to even measure that), but I'd guess it's still only 5% at most. The benefits to my happiness and fulfillment when coding are definitely noticeable though, and I think it is because I am able to spend more time in flow.

Edit: and for what it's worth, there are things that arguably have much greater impact on my ability to stay in flow than just the text editor: how good the debugger/REPL is, my familiarity with the language and libraries related to what I'm doing, etc.

Few minutes gain is simply not true. Its IMO closer to an hour. Having ability to jump asap to any letter on the screen and any file in the project in few keypresses without browsing trough the tree and son on, is massive speed up. It doesn't just save time, it saves focus.

This 100% -> Few minutes gain is simply not true. Its IMO closer to an hour. Having ability to jump asap to any letter on the screen and any file in the project in few keypresses without browsing trough the tree and son on, is massive speed up. It doesn't just save time, it saves focus.

* would argue that a lot of people who write things like 'it only saves a few minutes a day' have never actually tracked how much time it actually saves

* one good thing worth doing is to get a tool that tracks how much time you spend on different applications and websites during your work day

it will TRANSFORM your understanding of how you use your time

These are not "power user" features.

Every single IDE and text editor for programmers can do this stuff, and they are often the only features that 90% of users learn.

Some of them are, most of them are not - you cant really jump to ANY letter on screen without vim plugin (AFAIK).

Having quick access to options is paramount - like vscode F1.

Besides, huge majority of IDE users do not use keyboard shortcuts but browser trough its GUIs, even if the feature exists. Its the IDE mindset (personal experience).

> you cant really jump to ANY letter on screen without vim plugin

There are Ace Jump [0] plugins for most IDEs. imo, easier to use and more powerful than stock vi navigation commands.

> huge majority of IDE users do not use keyboard shortcuts but browser trough its GUIs

Does it count if you "browse the GUI" without ever touching the mouse?

I use the "search everywhere" [1] dialog in JetBrains by pressing double-shift all the time. When I used emacs, I would M-x tab-complete commands all the time. Same thing.

Which requires more effort: pressing 4-ish keys to spell out an editor command you use only a few times a day or trying to memorize every arcane key combination?

Also, does tabbing in the emacs command buffer count as "browsing the GUI?" I think so.

I say it all the time, but I think a lot of power vi/emacs users have not touched a modern IDE in a long time. Everything is keyboard accessible nowadays, and I would argue vastly more discoverable compared to vi/emacs.

I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.

[0] https://github.com/acejump/AceJump

[1] https://www.jetbrains.com/help/idea/searching-everywhere.htm...

I used vim for more then 5 years then switched to VSCode as it makes plugin setup much easier. I also use VS and JetBrains here and there and maybe I am biased, but I prefer code at this point.

Yeah, modern IDEs got some stuff from modern editors for sure. One of the primary pain points for me is that installation/setup of IDE is much more lengthy, they are pricey too - I can setup vim/code in minutes on empty machine. Just downloading/installing VS takes a bunch of time. This however has nothing to do with efficiency but counts overall.

> There are Ace Jump [0] plugins for most IDEs. imo, easier to use and more powerful than stock vi navigation commands.

The page you posted lists InteliJ Platform. Vim doesn't have such plugin OTB FYI.

> Also, does tabbing in the emacs command buffer count as "browsing the GUI?" I think so.

If tabbing is done via mouse, yes.

> Does it count if you "browse the GUI" without ever touching the mouse?

Ofc not, I prefer to have a GUI, I just don't think analog controller like mouse is good way to interact with it.

> I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.

That might have been a real thing when people did things on servers directly etc. Today there is almost 0 need to do so.

> I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.

There's nothing magical about it.

I prefer text based interfaces whenever available as they are generally more responsive, light on resources, use less network bandwidth, and are inherently compatible with SSH. They also tend to be very minimal, having far fewer extraneous features (ie fiddly distractions) due to the inherent design constraints.

If one isn't available though then I'm happy to use a modern GUI (my web browser is an example). In fact, GUIs consistently seem to be more newbie friendly so if it's a one off I might actually avoid a text based interface just to save time.

> I say it all the time, but I think a lot of power vi/emacs users have not touched a modern IDE in a long time.

Watch as my eyes roll out of my head, onto the floor, and then out the door.

Why is it that you believe the only reason why a vi/emacs user could believe those environments are faster to edit in is because they don't use IDE's?

The worst part is that most vi/emacs users actually DO have experience in both environments, whereas most of the people who want to claim vi/emacs isn't any faster don't. Yet they want to present themselves as an authority.

And I'm one of the people who refuse to use vim emulators in IDE's because they're never quite right (and never integrate well with the IDE).

> Why is it that you believe the only reason why a vi/emacs user could believe those environments are faster to edit in is because they don't use IDE's?

Anecdotal, personal experience, including seeing constant outright incorrect claims about graphical IDEs in threads like these.

The claims usually take the form of: "I use vi/emacs because I can do xyz using only the keyboard" - where xyz is something that most IDEs maybe couldn't do 15+ years ago, but which they all can do today.

I see this a lot from those who prefer IDE's.

It's not generally that people are saying it's impossible to do in an IDE, just that it's slower to do, and generally more awkward.

Just the other day on reddit I was having this "discussion" with someone, in which they claimed that because they have "find in files" in their IDE it's equivalent to vim `grep -iRl whatever`.

In reality I'm going to do what you're trying to do in a fraction of the time. IDE's have their advantages, but speed is not one of them.

Reply on news.ycombinator.com