[qsort]

It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs.

I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)

[sudahtigabulan]

> It's incredible how good of a design Vi is.

It's interesting how this design was forced into existence by the extremely limited hardware at the time:

TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem.

That's why we got commands like d), d{, D, etc. Trying to achieve the goal in one go, without any intermediate redraws.

[teo_zero]

>> It's incredible how good of a design Vi is. >It's interesting how this design was forced into existence by the extremely limited hardware at the time

Can we learn that if you design something for a constrained environment, it will shine when the limitation is lifted?

[makeitdouble]

We're only seeing the rare examples that worked out well.

For instance you don't want to code in assembly Facebook's backend. Blender would also be a completely different program if it was primarily optimized for the 68000. You usually will want different tradeoffs and architectural choices when the target platform drastically changes.

[flomo]

That's a great point. On modern systems, there's a false economy where editor stunts are not going make most people a significantly faster programmer. (Although some ppl just like them, e.g thinking they are "more powerful".) But on a very slow terminal, these things really did make a huge difference.

[chongli]

For people who love vi/vim, it's not really about being "a significantly faster programmer." It's about reducing friction between the changes you want to happen and them happening on screen. Editors with a lot of friction (that make you do lots of intermediate or repetitive steps to accomplish a task) can be really annoying to use. For some people, minor annoyances can be very distracting to the point where they take you out of your comfort zone and break your concentration.

Having your concentration broken when you're trying to solve a tricky problem can be a huge productivity drain. So in the end, an editor which may only save a keystroke here and there on average can end up being very productive for some people.

[Izkata]

I don't think it's even so much about keystroke count as it is the "commands" are more like a language that you can keep getting better in. For example, from above:

> d), d{

That's not two different commands, it's one action (delete) and two different motions (forwards one sentence, backwards one paragraph). Motions work on their own for moving the cursor, but can be combined with different actions and repetitions to multiply the sentences (commands) you can make. As you increase your vocabulary over time (there are a lot of motions and selectors (which are slightly different but used similarly)) you can keep reducing that friction between thought and screen.

[kryptiskt]

Yes, I'd say the composability of commands is vi's key feature. I can't remember any but the most common shortcuts in other editors. In vi I get so much more bang for the buck since I have easy access to all the commands I remember multiplied by the motions I remember.

[homebrewer]

And these commands are useless for programming unless you format source code in a very specific way, adding white space such that everything is split into "paragraphs" that can be thought of and operated on as a single unit.

As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST. Proper IDEs (not VSCode) in a hands of a power user who knows what his "hammer" can do (and how to invoke the necessary behaviour) are much more efficient at it compared to any text editor.

[chongli]

As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST. Proper IDEs (not VSCode) in a hands of a power user who knows what his "hammer" can do (and how to invoke the necessary behaviour) are much more efficient at it compared to any text editor.

That's assuming you're spending all day editing files written in the language(s) supported by your IDE. That assumes a great deal about your programming environment, toolchain, plugins, and configuration. Switch to a different language with different syntax, different idiomatic style, different IDE plugins, and you may be faced with a totally different editing paradigm.

This is where vi shines: the tool is excellent at editing text and is therefore 100% language-agnostic. It can easily handle jumping between files written in different languages, including plaintext files, configuration files, domain-specific language files, and otherwise many other files with syntax that may not be supported by your favourite IDE. Furthermore, it is equally happy working on files that combine different sections written in different languages. Sure, some other editors (such as emacs) and IDEs (such as RStudio) also support this sort of editing, but vi doesn't need any special support for it.

This philosophy, of making text the first-class citizen, in many ways mirrors the Unix philosophy. It also happens to be the case that vi (as well as its ex command line) provides a very convenient command for piping lines, paragraphs, and any other motion you desire through a shell command (or pipeline) of your choosing. This makes it very easy to format text using commands such as `fmt` or `column`, or apply line-numbers using `nl`. This, I believe, makes vi the ideal text editor for developers working on Unix or Linux software.

[mikojan]

> As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST.

Then why does your IDE not look like Scratch?

It is because nobody has found a better representation then text when it comes to editing concrete syntax trees.

Yes, you will rarely reach for d) or d} when editing Java or JavaScript. But the Vi paradigm does not stop at prose. And it does not stop at modern IDE capabilities either.

The Vi paradigm just enables people to do it faster. With less friction.

[sudahtigabulan]

> I don't think it's even so much about keystroke count as it is the "commands" are more like a language

It was about minimizing the number of redraws, but this indirectly might have led to fewer keystrokes too.

As you mention later in your comment, there are a lot of motions (which could be combined with deletion too). This is probably related to performance too, because they make it possible to achieve something quite specific like c3), with only a single redraw, and three keystrokes.

The "language" is undoubtedly a very good choice on part of Bill Joy. It wasn't necessitated by the hardware constraints, I believe. The separate modes neither. It's just that he would have wound up with less ergonomic key mappings.

Without the modes we would have to suffer using chorded shortcuts with modifiers, but they could still form a language. Think "M-3 C-d C-)" instead of d3).

Without neither modes nor composition (the "language"), it would have been even worse. A large number of single-purpose shortcuts, likely with multiple modifiers; he would have run out of (memorizable) single modifier combinations.

[flomo]

Absolutely, some people just love vi. Sometimes it fits their mental model, other times someone told them "real programmers use vim/emacs" and so they internalized and studied it. That's why most modern editors still have a vi mode. Obviously it works for people.

But if the 1980s UI Scientists came back with their stopwatches, I don't think the median vi-mode user would "win". Unless they were using a really slow terminal. (obv, we probably have some 1%ers on HN)

[chongli]

That may be true because 1980s UI scientists were most concerned with building efficient and intuitive UIs for the vast majority of people, not for 1%ers.

I know that I, personally, would not have been able to take some of the notes I took in university if it weren’t for vim and its affordances. Trying to keep up with a fast-writing math professor while typing a complete set of notes in LaTeX would not have been possible otherwise!

[davemp]

I’m not sure. Command based editing opens more doors than just optimizing keystrokes. There are edits I somewhat regularly do with Vim macros that save me minutes of typing and cognitive burden of examining refactor locations. It’s probably not going to be make or break, but I do think it’s significant in a p > 0.05 sense.

I imagine Vim is only just a local optima too. There are newer editors [0] that are more AST aware that I haven’t been able to fairly evaluate yet (not in the boring corp approved software list).

[0]: https://helix-editor.com/

[alwillis]

> There are newer editors [0] that are more AST aware…

With Neovim, you get the best of both worlds: it's Vim with AST support via Treesitter and LSP support baked in.

[wredcoll]

Any good recommendations for plugins to add commands to work on asts?

[arbitrandomuser]

This imo is a shortcoming of vim on modern systems, the action precedes the selection.

I would like to select first have a visual feedback of what I selected before taking action on it . Helix and kakuone have got this right .

I often find myself going to visual mode to emulate this.

[teo_zero]

I don't think it's fair to talk about "shortcomings" and "getting it right": it's a different approach and we must agree that personal preference will diverge.

Personally, I tend to use action-selection for small changes (1 to 3 objects), and selection-action for larger ones (as my brain, I've learned, becomes slower at counting above 3). So "delete 2 words" will be "2dw", but to delete the next 5 words I'll reach out for "v".

[codesnik]

it's not "emulating", it's exactly what you describe. And it's just one additional "v" away, can't be shorter than that.

[Izkata]

It's the same for selections, but motions are a little different. To use an example from above, d) is "up to" the next sentence (excludes the first character of the next sentence), while v)d moves the cursor onto that first character and so includes it when deleting.

[WuxiFingerHold]

As someone who started modal editing with Helix and then moved to NeoVim (LazyVim):

After a very short transitioning period (a week or so), I don't have this issue anymore (at all). Keeping coming back to visual mode is probably counterproductive for your transition. So maybe you should stop doing this for some time. Then you'll hopefully find yourself using the visual mode rarely.

[tasuki]

> I often find myself going to visual mode to emulate this.

It's just an extra key press. And you can choose which visual mode you'd like!

[nottorp]

That's the only reason I know some vi commands to be honest.

It's unbeatable when editing files on a remote server in a hurry and from random places that may or may not have good latency and/or bandwidth.

[eimrine]

> That's why we got commands like d), d{, D, etc. Trying to achieve the goal in one go, without any intermediate redraws.

This is 1/2 of explaining why vi family is the GOAT. The remaining explanation is that vi family is the only text editor which is able to be used completely without looking at the keyboard or touching the mouse even once. You can not achieve this if you have to use accord commands which are typically binded to what is selected by mouse. No vim-less text editor can ever provide one-click analog of o command (make a new line under the cursor from wherever column the cursor is at the moment of clicking).

[pugworthy]

I have used VI for many, many years and honestly use perhaps 25% at best of its abilities. But still I get comments about how fast and smoothly I can use it from other developers. Which I think speaks to how powerful even the basic editor can be.

And yes, you can also take my VIM plugin (for Visual Studio) from my cold dead hands.

[jxm262]

Same here. Tbh, you're comment just inspired to do a deep dive on VI. Wonder how much more productivity I can squeeze out if I spend an weekend focused on it.

[skydhash]

The productivity comes from not having to think about your editing while simultaneously realizing that you can do some complex editing really easily. I use Emacs and Vim both (I prefer Emacs) and It's quite nice when you can streamline some quick code edits.

My latest experience with Vim was helping a friend fixing some import with a React Native project. A quick grep on one terminal (I could have used quickfix) and using the vim fzf plugin to quickly locate the file. VS Code could have done this but the context switching and UI clutter is not great there.

As for emacs, the main advantages lies in the fact that so many great tools already exist there. Things like Occur, Shell Mode and Compilation Mode (relying on Comint, a more general feature for anything REPL), Project, Eglot, and Magit.

[tcoff91]

Now with neovim I feel like the plugin ecosystem is catching up to Emacs. Lua has unlocked the potential.

Typescript dev ex in neovim is light years ahead of what I achieved in Emacs. Neovim’s lsp integration is better than Emacs imo. Blink.cmp is so fast.

Magit is definitely far superior to anything in neovim though and so is org mode.

[skydhash]

I think Vim and Neovim is better suited as editors, meaning quick launch, fast localization of files and fast editing actions. And I like plugins that support this philosophy.

But the goals with emacs is to be a complete platform for anything plain text (with a bit of extra widgets). Almost whatever you need the terminal for can be replicated there, and they will share some common convention. Mail, file manager, music players, feed readers, PKM, PIM,… Tect editing is not so great, but text actions are (Slime is the best example).

I use both, but I prefer emacs’ extensibility.

[tcoff91]

Yes Emacs is still a better platform for building applications on for sure. Emacs lisp is a better language than Lua although harder to learn.

I used Emacs with evil mode for years until switching to neovim last year. It was really great.

[nyarlathotep_]

> And yes, you can also take my VIM plugin (for Visual Studio) from my cold dead hands.

First thing I install on any IDE/Editor.

[jghn]

It is worth knowing pure vi to some extent. To the point you raise, it's pretty much guaranteed to exist on any system you're on. That's not true of anything else, even vim

[maccard]

I can count on one hand the number of times I’ve had to use vi or nano and not had another option in 15 years programming. Optimising for that use case is not an efficient use of time.

[jghn]

Same, except it goes back 30 years, but it sucks when that one time comes up. I'm not suggesting one becomes a wizard. I'm suggesting understanding basic commands.

[nikanj]

As a pure cutting tool, a traditional saw is more powerful than a chainsaw.

That doesn’t mean it’s actually the fastest tool for the real job. Programming is not text editing

[_fat_santa]

I would say it’s incredible to see the quality and “durability” of Linux/Unix tools. The other day I wondered “how old is grep”, looked it up and realized that I use a piece of software that’s over 50 years old on a daily basis.

The fact that these tools have stood the extreme test of time is really something.

[ehecatl42]

Back in '94 I remember motherfsking some paper I was writing late at night in the computer lab. I think the wordprocessor was AmiPro, and it was giving me grief to the extent that I was at the point of violence.

Another person in the lab came over, invited me to his machine and showed me LaTeX in Emacs. We became friends (he a mathematician, I a zoologist). I bought beer; he brought 'computer wisdom'. Thirty-odd years later, those files are still perfectly reproducible. All of my kid's school reports from elementary onwards... LaTeX.

It's hard to overstress how important is longevity in a toolset.

Side rant on Emacs' keybinds: with orderless and vertico (and marginalia and whichkey) it is almost as fast for me to `M-x dir` as to `C-x d`, and in both cases I get a dired buffer. Aaand, `dired` is magic. History also tells me that it is older than Emacs.

\end{rant}

[thenthenthen]

What is the experiment?