It was the early 80s. Readability wouldn't be invented for about another 20 years or so.
Actually kinda serious. You need to be able to spare the RAM to have the comments, whitespace, large variables, breaking things nicely into functions, etc. I've got modules I've documented where the documentation alone would fail to fit into, say, a Commodore 64's RAM, as plain text. Early 1980s "big iron" would still be considered on the high end of embedded programming today. (In the sense that a Raspberry Pi is embedded programming.)
I first learned programming in BASIC on an 8K PET. The 8K was shared by the source code, data, the executing program and display memory.
Spaces were for suckers. Each line had a few bytes overhead so you put as many statements on each line as you could. You stuck to 1 character for your common variables (only 2 characters were significant anyway). You used the abbreviated name for commands. (This was around 81, 82.)
This is from memory, so probably not actually correct code but this is meant to print "IHN!" 10 times, wait about a second and then repeat. T is used as a FOR loop variable twice.
They developed these on a https://en.wikipedia.org/wiki/PDP-10. It's not like they were editing/compiling on the C64. Of course targeting small systems does influence the coding style, but...
A top-end PDP, according to that page, could address ~8MB, though I'm sure they didn't have it for a while; other charts on the internet suggest a top-end PDP-10 would get up to 33 mega Hz.
8MB for an embedded controller is no great ask and you have to crawl a ways down the spec sheet pile to get a 33MHz processor nowadays. A top-end PDP-10 would today put it roughly on par with an Arduino [1], although the Arduino would be a bit short on RAM.
Even if you have the space to spare on comments and long variable names, you've been raised in a culture that considers those insanely expensive extravagances.
The indentation and all-caps are not modern, and the MACLISP primitive names like TERPRI are unchanged from the 60s. Otherwise, the coding and commenting style would not really raise any eyebrows today.
I first learned of literate programming from this culture instead of Knuth, e.g. https://dspace.mit.edu/handle/1721.1/41983 ("The fourth section presents a completely annotated interpreter for AMORD").
I'm just saying yeah, expectations have definitely evolved, but it's not the case that PDP-10 hackers back then had not yet discovered or valued readability.
Yes, of course some people had that opinion. It was a fringe position back then, though.
It's less fringe today, but I'm still not sure "code should be optimized for reading, not for writing" isn't still a fringe position, at least as evidenced by what people's actions say about their beliefs, rather than their words. Lip service of that is probably at least not fringe any more, which is progress of its own sort.
All I'm saying is that the Infocom Imps developed on a computer that was plenty big enough for comments and readable names to be no extravagance. The sources above show it happened in practice and not just in theory. The company started after they'd been used to this kind of environment for years. (And they were at least adjacent to actual literate-programming pioneers.)
I'm not saying they were into literate programming, I'm saying it's misleading here to talk about what coding on the C64 was like.
That's a really interesting perspective. If I think about it an application really doesn't need to be large or complex at all to accrue a couple hundred kB of source code, libraries not included.
Actually kinda serious. You need to be able to spare the RAM to have the comments, whitespace, large variables, breaking things nicely into functions, etc. I've got modules I've documented where the documentation alone would fail to fit into, say, a Commodore 64's RAM, as plain text. Early 1980s "big iron" would still be considered on the high end of embedded programming today. (In the sense that a Raspberry Pi is embedded programming.)