[geocar]

I am still working on a good explanation. Here's what I've come up with so far:

I have noticed every page I scroll causes a comprehension loss of around 90%, so in reading something that is 10 pagefuls long, I might only be able to reproduce a tiny part of the program.

I find not scrolling, and just moving my eyes, I rapidly absorb the program, and I find most bugs just by reading the code. This practice is absolutely impossible for me if I have to scroll very far and made difficult by scrolling at all.

A lot of J/K/Q/KDB programmers do this because it is similar to APL, but I don't have an APL background. I simply do not know how to do this except to write horizontally.

I learned a lot about this method by studying Arthur's code (example[1]). He frequently recommends Iverson's paper[2]. I just try to make every character count because it's still taking up space.

Maybe keeping that in mind will help you read each word carefully -- maybe even out loud, if it helps.

[1]: http://www.nsl.com/papers/origins.htm

[2]: http://www.jsoftware.com/papers/tot.htm

[kev009]

To me it looks machine generated and it would be hard for me to mentally keep track and tick off "okay I know what the lines above do" but if it works for you and the people you work with are fine with it then good for you and I don't mean that sarcastically.

The way I work and similar to most people I know but perhaps with less screen real estate.. I can fit a hundred vertical lines of one text buffer comfortably on my monitors (plural), and I can have about a dozen buffers up at the same time. If needed, that can be the same document scrolled to different areas. I also use a tool like cscope or for some languages an IDE to get additional context (type info, available operations), and that's the only way for me to quickly comprehend truly large bodies of code (kernels, etc). I don't think your strategy would work well for the projects I work on.

[geocar]

We will see.

One of the fastest databases in the world written this way (kdb), and I was able to make an operating system kernel this way (kparc) and now a dynamic web server, and so on.

Maybe it would help you to keep an open mind to know it took some time to learn how to read and write code this way?

Perhaps it would also help to know it has actually improved my ability to work on code that looks more like what you are used to.

One of the hardest things to do is to look at something so alien, and suppress the recoil and discomfort and really be critical:

Here is something you cannot read; something others can do that you cannot.

Don't you want to figure out how to do something that others can do?

Maybe you will find other limitations: its alien nature is certainly a limitation, but maybe you're right and there are others.

But in the meantime, it produces small fast and correct code quickly, and that's pretty amazing. Maybe there are other benefits as well.

We will see.

[kev009]

I guess it seems like I'm bashing you by expressing shock but I don't mean that. Seriously, more power to you for expressing yourself in less space than I can or desire to.

[geocar]

I don't think you're bashing me.

I'm telling you the shock is normal, and that this is something you can learn to do.

However the desire surprises me: If someone does something I cannot do, and it is beneficial, I want to learn it.

Here I point to smaller, faster, and more-correct programs, written in less time. Why would any programmer not want to be able to do that?

I never understood Paul's Blub essay either, though.