> Why does it matter what things are called if the name of the thing might be a lie anyway?
It matters because the names you choose signal your intent.
As Knuth put it: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do."
A line of code is going to be read hundreds or thousands of times more often than it is written. The more someone has to scan around to discover the purpose or intent of something, the harder/slower your code is to navigate. And this magnifies by the thousands of times it gets read by humans.
Code has UX, just like all human interfaces have UX. We've already discovered that better UX is a good thing. Code is just another user interface to optimize for discovery.
Now I don't see names signalling his intent. What I do see is that the code is arranged carefully into a narrative with the following property: code you want to read next is either immediately or before the code that uses it (or even just that piece of functionality). Little care seems to be given to what things are called directly -- almost the exact opposite of what you're suggesting.
A little unfair to drop folks in the middle of the module. If you picked up War and Peace in Book 2, Chapter 14, you'd probably be pretty confused too.
I realize the program as a whole suffers from similar faults, but let's try to be fair.
Edit: Ok, I skimmed most of both files, and my initial impression seems to hold: there are short names, some are abbreviations, some are acronyms, but I didn't see (could have missed it) any "meaningless" name (ie. one that wouldn't have an expanded form of one or more words).
But it's kind of beside the point with Knuth's work. Of course he uses short names: he just spent 3 pages of (carefully edited and typeset!) text to hammer its meaning into your mind. There's no way for you to misunderstand, or not understand, what the symbol signifies - so what does it matter what symbol it is, exactly? [EDIT2: it matters when typing]
If you (anyone reading this, I mean) want to use these as an excuse for using meaningless and short names as identifiers, remember: these are ok if bundled with 80 lines of narrative explaining them...
Of course these are "ok", but it's not because there's "80 lines of narrative". Sometimes there's only one or two. Sometimes there's none.
What makes this "ok" is that it's clear that the author intends you to read all of it. Code. Literature. Everything.
I don't know why, but for some reason, a lot of people think it's okay to "scan" or "skim" code. To just not read it. They wouldn't think of doing this to a good novel, but they'll do this to code.
Literate programs trick you into reading a novel with bits of code in-between, such that you can digest the code and non-code parts at the same time really aiming to cement both your (the reader's) understanding, as well as the author (the programmer's) understanding†.
But listen, we can choose to actually read code too. It's hard. Much harder than just "scanning" it, but we can do it. And with some care and taste, that code can actually be as good as "80 lines of narrative".
[†]: Mathematics has been doing this for years because it's often really hard to understand complex things from the notation alone, especially when you have to invent a new notation just to discuss this new thing you're thinking about!
Well, the "80 lines" was supposed to be a joke, guess it failed... Anyway:
> And with some care and taste, that code can actually be as good as
That's true. Also because modern languages are more flexible than the ones in the 80s - probably, I wasn't around back then, but I remember from learning C that there was "old style" where all variables had to be declared at the beginning of the function, and that "new style" (second half of 90s?) was to declare them at the point of use. My guess would be that this and other similar limitations were the reason for writing CWEB. The order and flow of the presentation is very important to Knuth, so he wrote a tool which allowed him the freedom of putting text and code in the way he wanted.
Modern languages are in general flexible enough to make this a non-issue, as the presentation can be safely included in the source, and you have much freedom in structuring (ordering) the code, too. CoffeeScript is one example of "literate programming in the modern world".
That being said, I think you greatly underestimate how much care is needed to write code like this. I'd guess that not many professional programmers could do this - it's that hard. But yeah, beautiful when executed well.
> As Knuth put it: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do."
I've never heard that one before but it's brilliant. That second sentence should be the opening sentence of every introductory programming course.
Yes that's right, 1mb of source code text, all in one file.
If you haven't had the pleasure of a well-considered literate program, it might be funny to hear that I'd actually prefer this to a lot of shit I have had to deal with in my life...
A well-written literate program is a joy to work with. To be able to genuinely understand a complex program's design by reading well-written prose which forms part of the source code. Literally reading code like a book, finding that it effectively has a plot and characters with understandable motivations, properly introduced and their places and relationships clearly understood. Done right, it can work so well.
The only software I ever worked on in which the customer never reported a single bug was written entirely in literate code.
The software I work on now is so much at the other end of the scale that sometimes when the customer reports something, there is a signficant period of investigation before deciding if it's a bug or if that's how it's meant to work.
BTW, that .web file is not meant to be read directly (even Knuth doesn't read that file, except to make edits). The form in which it supposed to be read, and the form in which it was published as a book (though with some added typographical/indexing niceties) is the "woven" form, e.g. what you can find here: http://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf
It matters because the names you choose signal your intent.
As Knuth put it: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do."
A line of code is going to be read hundreds or thousands of times more often than it is written. The more someone has to scan around to discover the purpose or intent of something, the harder/slower your code is to navigate. And this magnifies by the thousands of times it gets read by humans.
Code has UX, just like all human interfaces have UX. We've already discovered that better UX is a good thing. Code is just another user interface to optimize for discovery.