3 ms·

In your opinion. I have no issues with it. But it helps if you work a lot with k/j I guess. It is not write only at all; it just feels like it more as it is so

In your opinion. I have no issues with it. But it helps if you work a lot with k/j I guess. It is not write only at all; it just feels like it more as it is so terse that if you change something, it will generally affect more % of the code than in other languages. And the readability; again it is so terse that it probably will take you more time to inderstand an A4 of this than an A4 of C#, however, I find it easier to comprehend complex code written like this than the same code spread out over 100s of files with design patterns sprinkled on top. But ymmv; just until you did significant work in an APL, I am not sure you can comment like you did. It is another world. In short: Like Whitney, I hate scrolling in code. Multiple high res monitors and with bunches of tabs and files open and then scrolling and trying to figure things out with IDE ‘jump to implementation’, ‘find references’ etc is just really not very efficient compared to this. In My Humble Opinion.

OneWordSoln 8y ago
I, too, hate scrolling in code (and almost never used Visual Studio's "jump to X" navigation helpers) but the reality is that each and every non-trivial program we write (which is practically ALL of them) will never come close to fitting on our screens. The real problem is always the limit of our ability to hold the mental model of the code within our mindscape as we operate on the patient. For me, having another abstraction to wade through on the screen is just another murky impediment to my reshaping the model. As an inveterate simplifier of code and its formatting for clarity, I have gone to only doing a single thing on a single line, even variable declarations [Note I only have personal projects now]. The primary purpose behind this is that such extreme simplification will make it easier to process algorithmically, for both meta-code (i.e. IDEish) work and to narrow the horizontal extent of its format on both paper and screen. Now that I think about it, it seems that Whitney's perspective might flow from his not using a code-folding editor, where each chunk of code can be collapsed to its header comment that states what it does. Aren't we usually dealing with the higher-level flow of logical chunks instead of the itty-gritty details of each?

OneWordSoln 8y ago

I, too, hate scrolling in code (and almost never used Visual Studio's "jump to X" navigation helpers) but the reality is that each and every non-trivial program we write (which is practically ALL of them) will never come close to fitting on our screens. The real problem is always the limit of our ability to hold the mental model of the code within our mindscape as we operate on the patient. For me, having another abstraction to wade through on the screen is just another murky impediment to my reshaping the model. As an inveterate simplifier of code and its formatting for clarity, I have gone to only doing a single thing on a single line, even variable declarations [Note I only have personal projects now]. The primary purpose behind this is that such extreme simplification will make it easier to process algorithmically, for both meta-code (i.e. IDEish) work and to narrow the horizontal extent of its format on both paper and screen. Now that I think about it, it seems that Whitney's perspective might flow from his not using a code-folding editor, where each chunk of code can be collapsed to its header comment that states what it does. Aren't we usually dealing with the higher-level flow of logical chunks instead of the itty-gritty details of each?