Straw man.

I'm not proposing "dropping the typing requirement".

I think having the program small and fit on the page is more important than types or no types.

To that end: I don't even want to have the argument about types because I think they're so irrelevant.

I'm sure most professional programmers could write an SQL92 implementation in around 1000 lines; Again, types or no types.

Here's Arthur's SQL written in 20 lines (including lexing and parsing):

http://web.archive.org/web/20060505221834/http://kx.com/q/e/...

Here's Steve Apter's relational (not SQL) database in 16:

http://nsl.com/k/t.k

"I don't even want to have the argument about types..."

But that is exactly what you chose to do in your original post.

No it is not.

I'm happy to see an argument that (having or not having types) is more important than a short program.

but I'm not happy having an argument whether to have a language with types versus one without.

That's what "I think types are irrelevant" means.

It seems like at least some people realise this e.g. https://news.ycombinator.com/item?id=8999077 but if after re-reading my post you disagree, let me know how I could better articulate what I mean.

I should have written 'the post to which I was replying' rather than 'your original post.'

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. Just as professional mathematicians need to be able to follow proofs that occupy more than one page, professional programmers need to be able to reason about code that occupies more than one page.

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