Please don't descend into name-calling.

What PeCaN said there is no different from what masters like Chuck Moore and Arthur Whitney say. Maybe you disagree, maybe not everyone is like those guys, but "juvenile fantasy" and "programming puberty" is an extremely shallow dismissal—which https://news.ycombinator.com/newsguidelines.html specifically ask you to avoid.

We detached this subthread from https://news.ycombinator.com/item?id=22523047.

Maybe I should've said a "screen" instead of a "page" (if you have two files open side-by-side and they both fit on your screen it's the same benefit). And I admit it is slightly hyperbolic (to make a point about the virtues of being able to see a significant portion of your project at once). Large projects will be more than one screen of code, although perhaps surprisingly few. (This actually influences how I organize code, in that the "screen" becomes a logical unit, and I try to keep the API surface of each screen really small.) I'm working on a programming language project to try to get even denser.

>Good luck fitting an operating system, web browser or air traffic control system into a page of code.

Aaron Hsu's co-dfns compiler (optimizing compiler for a subset of APL to the GPU) is 3 screens https://github.com/Co-dfns/Co-dfns/tree/master/cmp (I can fit the entire codebase on my three monitors).

This K text editor is way less than one screen https://kparc.com/edit.k (Funny you should mention OS. I'm eager to see how many pages kOS is. AW notoriously hates scrolling.)

Web browsers are a lost cause, I'll give you that one.

> This K text editor is way less than one screen

Where's the handling of encoding when loading and saving? Where's the handling of different line-endings? Where's the error handling?

Would have been nice to see something approaching real-life code rather than these toy samples.

> I'm sorry, but that sounds like the juvenile fantasy of someone who is still in their programming puberty.

For larger applications what PeCaN was saying still mostly holds true.

I work on large (1-10 million loc systems) enterprise java code bases and write some side projects in k as a hobby.

I can get the equivalent of around 30-40 java class files on screen at once with k.

Even on poorly written enterprise code bases code is clustered and your “working set” of code files is quite small and is not strewn all over the codebase.

Of course you still need to understand the core system abstractions + base platform + common library code.

...and in idiomatic K code, you apparently still need to constantly wonder what 'a' or 'X' means in your current context, with likely 5 different usages on your screen at once.

I have not experienced that.

If you see many different usages of the same identifier then it’s probably a common construct/pattern you aren’t aware of.

In the same way as ‘i’ tends to be used as the current array index in a for loop - but devs don’t get confused by seeing ‘i’ used in lots of different loops.

Or kotlin devs seeing ‘it’ or class based language devs seeing ‘this’.

So you claim it never happens that two people working on different parts of the code decide to use the same identifier for completely unrelated things?

Seems to me that is bound to happen pretty frequently when the expectation is to use only one- and two-letter identifiers.

there almost certainly is an encoding such that every program any human will ever write fits in 128 bytes, though I doubt we'll ever design one. to convince yourself of this, notice that you don't expect to ever produce two programs with the same blake2 hash.

there's a lot of room for improvement in conciseness of code. I would still be surprised if it was meaningfully possible to write a full-featured modern OS with one page of APL

I think you'd have to write the "Do what I mean." interpreter before you have any chance of making programs that compact.

Hashes do not encode; to convince yourself of this, try to recover a program from it blake2 hash.