> With regard to your larger issue, almost all programs other than exercises are vastly larger than a screenful, so either the way all software is written is completely wrong, or your preference for screen-sized programs is irrelevant to the real problems of writing real-world software.

Agreed.

Arthur wrote an SQL in 20 lines of K, and a dynamic window manager in around 60 of C. His programmers editor with syntax highlighting easily fits on a page.

kOS's kernel is under 60 lines of C as well (including annotations; paging, filesystem, syscalls, etc).

Where I work, I wrote an RTB service for digital advertising demand-side platforms- implements HTTP, application protocol decoding, maps and bidding in under 100 lines of C. I fit a video player with VAST+VPAID support in 42 lines of Javascript.

So it follows how programmers write software is completely wrong.

However the inertia will be hard to overcome.

A few examples, impressive as they are, do not make the case that most of the world's programs can be replaced by programs of no more than one screenful. If you really know how to do this, you could achieve fame and wealth of Edison-like proportions as the person who revolutionized software development. If all you are going to do is brag about it in HN comments, that is not a profession, it is a hobby.

These few examples don't need to make the case that "most of the world's programs can be replaced by programs of no more than one screenful", because again that's your strawman, and not my argument. People pay millions of dollars for kx's database so it's not by any reasonable definition mere "exercises", and it's certainly not "vastly larger than a screenful".

I'm writing this way; I'm finding value writing this way, and at the moment I'm making no other claims other than the shortness of a program is the single best indicator of correctness, performance, and "reasonableness". It's certainly more important than a "types" argument.

While your best counterargument against short programs is inertia, suggesting we shouldn't leave the trees isn't helpful. You should try it. You might like it.

"at the moment I'm making no other claims other than the shortness of a program is the single best indicator of correctness, performance, and 'reasonableness.'"

If you had not strayed from that position, I would not have joined the discussion. I happen to agree that there is an inordinate amount of unnecessary complexity in the present code base, but I think it is an orthogonal issue to that being raised by the original article. That is because it seems to me that the main causes of this introduced complexity is developers' poor understanding of the requirements they are trying to satisfy, together with a trial-and-error approach to programming, rather than the language features covered by the original article.