The article is a bit all over the place with its arguments but I agree with the general principle.

What the article doesn’t seem to focus on is to me the main advantage: composability. Every command in the terminal can be roped together with a common interface. Some people belittle that interface as “stringly typed” but in comparison to an IDE or other graphical programs, where nothing is composable, it’s very good indeed.

This is the thrust of Stephenson’s “In The Beginning Was The Command Line” (1999) - he doesn’t come right out and say Unix is an IDE, but the whole essay implies it. And historically, it did basically come together as one.

Good points said in a counterproductively abrasive and over-the-top opinionated fashion that smacks of “it’s invalid for you to be doing things that have needs I don’t have”. (Or, perhaps, “You d*mn kids get off my lawn”.)

Graphical tools are transient, POSIX is forever.

I agree with most of the sentiments, but I’ll stop using a GUI Vim frontend when POSIX implements support for terminals to do things like wavy underlines that allow for spellcheck in my Markdown, and syntax hints in my LSPed languages to be less “loud” than changing the background colour.

Ancient GNU systems might come with screen but this program is incredibly unpleasant to use.

For you, maybe. It was only a few years ago that tmux even gained the ability to be configured to replicate my preferred multi-row screen footer, and it still intentionally omits the ability for tabs to be serial terminals that I depend on for things like the /dev/ttyUSBn serial consoles on my embedded Linux devices or my “USB to TTL Serial” adapters I use for things like interfacing with microcontrollers.

(Seriously. Why is the only serial terminal emulator that feels like a proper UNIX thing instead of a text-mode port of a Windows application built into a screen multiplexer?)

Makefiles

Ahh, Makefiles. More helpful than bare shell script, still wasting more valuable programmer time than cargo run/uv run.

That said, I will say there’s something inordinately cozy about using Open Watcom C/C++’s WMake builtins to write a Makefile which will build equally well on Linux or MS-DOS.

There are, however, many plugins for vim that might be of interest. vim-syntastic is useful for people who are too lazy to run a program to find errors or are hopelessly dependent on their IDE doing all of the actual programming work for them.

• bacon clippy in a terminal on one monitor (it’s a Rust thing which re-runs the build checks and lints whenever you save your changes, and then orders them so the error that caused parsing to break down doesn’t scroll out of sight like with cargo clippy)
• gVim with ALE and coc.nvim on the middle monitor for format-on-save (why fight to get Vim’s word-wrap perfect when you can just let a code/markdown beautifier do for word-wrap what LaTeX does for paragraph justification?) and code actions like syntax-aware “rename all occurrences of this identifier”.
• Zeal waiting to be Super+Z’d into/out of existence with full HTML rendering for find-as-you-type offline dumps of syntax references for languages and libraries that don’t bother to support man or texinfo.
• GoldenDict-ng waiting to be Super+D’d into/out of existence for as-you-type access to offline dumps of dictionary, thesaurus, and etymology sources like Wiktionary and Etymonline.

No need to do things excessively manually just to stand on principle.

Version control

OK, I admit I’ve been lazy here. I use git gui overlapped with a split gVim on the central monitor to be called up with Alt+Tab instead of gitting gud at cherry-picking lines and hunks using only the keyboard to detangle a file where I unthinkingly intermingled two unrelated changes.

TL;DR: The original article is valid points buried in a crust of “My own argument is invalid because it can be mad libs’d into an argument that I’m a wimp because I code in something higher-level than assembly language”.

…plus, as someone with a certain degree of sensory processing issues, I can say that they missed out on expounding on how distractingly cluttered with functionality you don’t need IDEs are. Vim is the FocusWriter of code editing.

I like the idea – UNIX(-like) OS as an IDE – but that „compatibility table“ is rather an argumentation faul than relevant information. Java runs almost everywhere including OS/2 and Haiku, so you can run Eclipse, Jetbrains and NetBeans IDEs there.

An IDE is simply a means to an end, and whatever IDE takes you efficiently to the end is the IDE of choice for you.