[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.

[doix]

Yeah, vim was invaluable when I worked in the semiconductor industry. Lots of perl, TCL, SKILL (a lisp dialect) and giant verilog netlists. Languages which don't really have proper IDEs or great all in one tooling.

Now I'm a webdev with everything written in typescript and just use Cursor (basically vscode) with the vim plugin. i miss the tab model from vim a lot, but apart from that the vim plugin is close enough.

[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.