Lambda the Ultimate

I propose that the best way to make a program good is to make it comfortable to read linearly, like a book or a paper.

I may be a very strange type, but most often I do not read papers linearly. What is even more strange, I find it easier to read some papers in printed form exactly because it's possible to have multiple full-sized pages "displayed" side by side.

Of course, I do not object to readable code at all.

It's certainly a way of making a program easy to comprehend, as to it being the "best" way I'm unsure. Once you have a large code base any strictly linear narrative is going to break down.

i don't know your history, ehud, but that leaves me wondering how often have you had to fix bugs in other people's code?

maybe we're understanding "readable" in different ways, but one person i work with seems to hate typing. no variable is more than a few letters long. he also "hand optimizes" what he writes, rather than trying to express the aim of the code clearly. those seem like the two ways in which code can be considered (un)readable (syntactically and semantically). both make my life a misery.

I spent a few years doing just that. Can't you recognize a joke when you see one?

That's the spirit...

I gather that it used to be a common practice to print program listings and read them. I hear about it in anecdotes from programmers I admire, and I also see that many older programs appear to have been written with reading/printing in mind: they contain pagebreak characters, include their user-documentation in comments, and are broken into logical sections of a couple of pages or so. The CMU AI Repository FTP server is an interesting source of 20-year-old programs like this.

Let me share some quotations that have stuck in my memory:

The mask layout program by BillCroft at Purdue EE department - This is a truly awesome C program that could do VLSI scale designs on a PDP-11. The implementation included the command processing, high-resolution graphics, and custom database. Amazingly the program was only about half an inch thick and could be read in an afternoon. (Contrast this to my own companies' graphics drivers for the same device which ran ten times this for the drivers alone.)
-- Ward Cunningham, Wiki

I was the one who decided to rewrite the [program listing generator] from scratch as a standalone program, partly because I wanted to add substantial new facilities, such as the ability to list many files at once and provide inter-file cross-references.
-- Guy Steele, ll1-discuss

Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples - both good and bad - to facilitate learning. But how many programmers learn to write programs by reading programs? A few, but not many. And with the advent of terminals, things are getting worse, for the programmer may not even see his own program in a form suitable for reading. In the old days ... programmers would while away the time by reading each others' programs. Some even went so far as to read programs from the program library - which in those days was still a library in the old sense of the term.
-- Gerald Weinberg, The Psychology of Computer Programming

How times change! People measured programs in "thickness", wrote special listing generators (in 300 pages of PDP-10 assembler!), and dreaded that one day people may not sit down and read programs, not even their own. Have we advanced beyond such things, or is a Good Thing slipping off the radar?

I'm onto my fourth pbook'ified program now, and I'm very happy with the effect it's having on my programming style. If you try it out then please let me know how it goes!

that was largely through necessity, though.

If I read a story book, I probably accept to read it cover to cover. (But this will not work with Frank Herbert's Dune trilogy --- it has multithreading written all over it.)

But a program/proof has a structure richer than a storyline or timeline, namely, directed acyclic graph of dependency. A procedure/theorem may use a subprocedure/lemma, and I may or may not care enough to dive into the code/proof of the latter. I want to read it as at least a tree, with complete freedom to expand and prune child nodes at my discretion.

See Structured Calculational Proof by Back, Grundy, and von Wright, or generally explore the Computer-Supported Mathematics page. There is an HTML example.