C programmers really need to be banned from naming things. Naming things is a certified “hard problem”… but it’s not that hard!
C programmers really need to be banned from naming things. Naming things is a certified “hard problem”… but it’s not that hard!
In any case, (a) UNIX (as it was spelled then) antedates C, so it's more that the UNIX spelling conventions influenced C's development; and (b) lots of earlier and later programming languages have had mystical abbreviations. For example, ALGOL68 replaced “integer” with “int”, for reasons I have never understood; Wirth's original CDC 6600 had a data type “alfa”, which was a 10-character string; William Wulf's Bliss language had library routines with names like “getnum” rather than “get_number”. In PL/I, you can write “proc” for procedure, and “dec” for “decimal”.
Me, I prefer to program in a language that has primitive procedure names like “call-with-current-continuation”.
I love most of the language, but I'm convinced it was written by people who type 300 wpm.
Today terminals are fast and highly functional, memory is cheap, CPUs are blazing fast too. Our modern bottleneck is not the computer struggling to intake commands fast enough, but people struggling to understand what the heck Bob was trying to accomplish 3 years ago.
And for that, a verbose scripting style that helps not need to look up every single parameter in the manual is very helpful.
It's helpful to understand the context which evolved this desire for terseness.
A) in the 60s through to the early 90s, to communicate with the "computer" you used a terminal. They used a serial connection which started out life very slow. Sending 7 chars (integer) was measurably longer than 3 (int). Commands used a lot (ls) benefited from being short.
B) CPUs were slow. It's hard to fathom now but not only were the CPUs slow they were shared (in many cases) by multiple terminals. Simply processing extra letters, matching strings to known commands, goes up the longer the command.
C) storage costs would make your eyes water. Source code was terse partly for compiling performance, but also to lower storage cost. "Huge" storage meant "a few mega bytes". Most storage was measured in kilo bytes.
D) same for ram. Storing the word "integer" in ram (in your text editor) took up ram that could be used elsewhere.
Of course none of this applies now. But unfortunately habits learned early are hard to break.
This fostered shorter meaningful "names" for everything from types to variables to system commands; things were far easier to grasp when short operations fitted on a single line, at worst spilled onto few others, and functional groupings fitted on a screen.
(Of course, you should use mosh instead of ssh with high ping servers when you’re not actively trying to appreciate the terseness.)
DEC systems often had (at least) two options for serial communications, a cheaper PIO-based one and cards that could do DMA (yes, DMA for 300-9600 baud serial lines). The former would cause more CPU load. Yes, minicomputers where so slow that handling a 9600 baud serial line (~900 characters per second at most) wasn't negligible.
It’s possibly more to do with the imposition of having to send commands with a teleprinter running at 75 baud than a preference for terse commands. Terminals in the very early 70s weren’t much better. Limited to 72x20 characters and not hitting the heady speed of 9600 baud until much later in the 70’s.
Get-Content -Tail 20 -Wait
Nevermind that it has tab-completion of not just the commands but the parameter names too. Nevermind that it deals with piping actual objects around rather than forcing everything to be a string. What really matters to developers hearts is that everything they type is 2 characters or less and can demonstrate their extensive memory for whether it's du or df for checking space on a drive.