Comment by vincent-manis | Hacker News Reader

Comment by vincent-manis | Hacker News Reader

Parent Full thread

Actually, I'm very glad that Thompson, Ritchie, and friends used these strange names for the commands they implemented (supposedly because they didn't like to type long words). This leaves longer, more meaningful names open for me to use in naming commands I write.

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

>> For example, ALGOL68 replaced “integer” with “int”, for reasons I have never understood;

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.

Find a high ping server today and try to admin it over ssh. You’ll appreciate the tenseness.

(Of course, you should use mosh instead of ssh with high ping servers when you’re not actively trying to appreciate the terseness.)

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

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.

WRT actual code editing and terminal usage the early years were dominated by text interfaces with typically at most 25 lines by 80 characters. (Greater height and width came with a steep increase in price).

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.

and 300 baud, and before that, punch cards

With 64 kilobytes of core memory to run in (and no swap), linkers were usually limited to 6 or 8 character symbol names. Compilers could let you name your variables anything but "my_value" and "my_valence_count" would still represent the same thing in memory. Being purposefully parsimonious with your names was good defensive programming practice.

You must really like powershell then.

I love most of the language, but I'm convinced it was written by people who type 300 wpm.

I think powershell is meant to be tab-completed, more than typed at 300wpm? I still prefer terse, though; pretty sure I can type `tar xvf` faster than I can tab-complete `tar --extract --verbose --file`.

Yeah, thats the issue, tab completion can only do so much.

Not the parent commenter. I prefer PowerShell to any Unix shell. It can be tab-completed, including every cmdlet's parameter names. Writing PowerShell scripts is a delight. In fact I can write the core business logic in C#, VB, F#, or any other CLR language, and expose the shell logic with a thin PowerShell wrapper.

Yup. IMO PowerShell's decisions were right for the modern age, just like Unix's decisions were right for its age.

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.

the underlying issue, is that tab completion can only do so much.

> (supposedly because they didn't like to type long words)

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.

That seems backwards to me, short commands should be where users place their daily workflow of aliases. Longer names should be where the kind of static, shell scripting "API" sits. Imagine a world where we could set 'mv' and 'ls' to something other than the `mv` and `ls` binaries without breaking our systems...

That's the NixOS world.

Speaking of mystical abbreviations — CAR, CADR, CDR !

Reply on news.ycombinator.com