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