This is also one of the reasons I write C++ with vim without any auto-completion nor fancy plugins (I do use syntax highlighting though, but I think it comes by default with vim nowadays), as well as using GNU screen -- not every machines install tmux by default, surprisingly. In case I need to login into some random Linux box, I'm sure I'll be almost as productive as I am on my own machine.
You mean, you're almost as unproductive on your development machine as on a random remote system that has no tools. And you somehow regard this as some sort of playing field leveling that generates an advantage.
Imagine a car mechanic that won't use a big hydraulic lift that hoists a car in seconds and lets him walk under it, claiming that by using a manually cranked portable jack, he can be almost as productive when fixing something by the roadside with emergency equipment as he is in his garage.
If you ever meet such a mechanic you can be sure that he programs computers as a hobby.
I assume this is tongue-in-cheek, but I don't think the comparison works at all.
I spend maybe 1% of my working hours (being generous) using `ls` and something like 50% (likely more) using my editor.
If there is some alternative to `ls` that makes my `ls` workflows 2x faster, my productivity increases by 0.5%. If I use a sub-optimal editor that makes my workflow 2x slower, I lose 25% of my productivity.
When I need to login to a remote box, I am also very likely to need to use `ls` since I am less familiar than on my own machine, whereas I am unlikely to do any sort of heavy development work (typically I just need to edit a couple configuration files, or do some git operations).
I did the same thing back in they day.
I developed on SCO (and, later, Unixware) on a PC, all of the clients were running the gamut of Unix OSes: HPUX, DGUX, AIX, SunOS, you name it.
Most of the time was spent on our box in the office, but I was constantly bouncing back and forth to client systems. Either on site, or over the modem. Having to juggle Termcaps and the whole thing. It was polyglot machine/OS world back then.
Just had to learn to get the best out of a baseline set of Unix tools. vi instead of emacs, awk instead of perl. Master those and never be left wanting on a new environment, so I can hit the ground running. No need to "bootstrap" (if the client would even let you, not always). Couldn't even rely on a C compiler.
I’ve been on machines in the last few years that didn’t have screen either. Maybe it was a minimal install or something, but I specifically remember having to install it to get some long running stuff going.
(Thinking it was Ubuntu server, but guessing someone will correct me)
Tmux vs screen is an odd one; it kinda feels like screen was included in the era when people were actually trying to make the default install on servers kind of nice to use with a functional set of assumed programs. And now, it is fairly widespread just due to legacy.
Nowadays, and possibly for the better (every line of code is a potential bug and every bug is a potential vulnerability) it seems like systems don’t want to include this sort of stuff. So, I’m sure if the decision were made today, tmux or screen, tmux would win. Unfortunately, “none” seems like the real future option…