4 ms·

This code is a horrid abomination. I don't care if this guy is a genius and could single-handedly write the best OS in the history of computing; his code is wri

This code is a horrid abomination. I don't care if this guy is a genius and could single-handedly write the best OS in the history of computing; his code is write-only, unmaintainable garbage. There's nothing elegant or praiseworthy about this at all.

ulucs 8y ago
If you don't know the language, of course most things will seem understandable b[Ii]{h:#x;l:0;while(h>l)$[y>x[i:/l+h];l:i+1;h:i];l} b -> function name [Ii] -> type declaration h:#x;l:0; -> initial definitions And the rest of it are bog-standard binary search operations with implicit return of l. Honestly, it's more understandable than Java with annotations or other magic constructs
- caymanjim 8y ago
  itsnotthatitcantbereadbysomeonewhoknowsthelanguageitsthatitsincrediblydenseandhardtoreadandlacksanymeaningfulcontextclues
  - 3xblah 8y ago
    I actually had no problem reading that! At first glance, it looks unsightly but when one actually starts reading it (all of it, not just looking for "clues"), how it looks makes little difference. These threads that mention k are always entertaining. There is usually some amount of comments like yours. There is this concept called "Tall Poppy Syndrome". I am not sure what we might call this stuff here (it should have name), but we see some of it every time k comes up in a thread on HN. Fortunately we also see people commenting who like APL or at least are curious. Not everyone is trying to cut Arthur Whitney down for being good at what he does.
  - yiyus 8y ago
    sentence(lang HumanLanguage){ if(lang!="EN"){ throw_exception(UNKNOWN_LANGUAGE_EXCEPTION); } with subject(combine_adjective_noun("context", "clues")){ verb[to_be::present::plural]"are"([adjective]"overestimated"); } full_stop; } Do you find this more readable than a simple English sentence? AW's code is way too terse, but most code is much more verbose than I'd like it to be. Finding the sweet spot is difficult (and it may change when you are coding just for yourself and when there is a larger audience). In order to find a good compromise, it is always interesting to explore all the possibilities in both directions. We have code with many safety measures, extensive comments and visual clues and we have code like this and, in contradiction with every theory, the terse style is doing quite well in terms of bugs and programmer efficiency. Why? Is that a coincidence? Could we have the best of both worlds? I do not say you should use this style for your projects, you don't even have to like it a little bit, but criticizing it because of its disadvantages without trying to understand its advantages is not a very productive point of view, in my opinion.
tluyben2 8y ago
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
Thank you for saving me the trouble of having to write the same thing. We programmers often seem to forget that we spend far, far more time reading code than writing it, therefore readability should be a (if not the) primary consideration when engineering it. That said, I do understand where Whitney's terseness impetus comes from: I have always lamented how little of my code will fit on the screen, with the number of vertical lines being the limiting factor; that is precisely why my taskbar is on the left-hand-side. (And don't get me started on monitors designed for watching wide-screen movies -- 1600x1200 FTW!) As such, I can't really fault his intention as much as his execution, and I feel that ultimately the solution to his (really, our) problem is that all our code (not just his) needs an IDE that can expand such terse definitions as per the current programmer's preferred style. This has been my perspective for many years, especially after wrangling various SQL dialects and the mostly awful formatting preferences of my peers. As I see it, the ideal solution is to store all code files as its token stream and have a default format that can be customized by each programmer in the IDE. As a result, each program will be stored as its pure content (which would help with version control (so long as whitespace is ignored)) AND each programmer would get to work with their preferred perspective. Of course the problem with this methodology is that the tokenizer and formatter better be flawless or you're f*ed, not to mention the fact that there are various IDEs that people like to work with.

ulucs 8y ago

If you don't know the language, of course most things will seem understandable b[Ii]{h:#x;l:0;while(h>l)$[y>x[i:/l+h];l:i+1;h:i];l} b -> function name [Ii] -> type declaration h:#x;l:0; -> initial definitions And the rest of it are bog-standard binary search operations with implicit return of l. Honestly, it's more understandable than Java with annotations or other magic constructs

caymanjim 8y ago
itsnotthatitcantbereadbysomeonewhoknowsthelanguageitsthatitsincrediblydenseandhardtoreadandlacksanymeaningfulcontextclues
- 3xblah 8y ago
  I actually had no problem reading that! At first glance, it looks unsightly but when one actually starts reading it (all of it, not just looking for "clues"), how it looks makes little difference. These threads that mention k are always entertaining. There is usually some amount of comments like yours. There is this concept called "Tall Poppy Syndrome". I am not sure what we might call this stuff here (it should have name), but we see some of it every time k comes up in a thread on HN. Fortunately we also see people commenting who like APL or at least are curious. Not everyone is trying to cut Arthur Whitney down for being good at what he does.
- yiyus 8y ago
  sentence(lang HumanLanguage){ if(lang!="EN"){ throw_exception(UNKNOWN_LANGUAGE_EXCEPTION); } with subject(combine_adjective_noun("context", "clues")){ verb[to_be::present::plural]"are"([adjective]"overestimated"); } full_stop; } Do you find this more readable than a simple English sentence? AW's code is way too terse, but most code is much more verbose than I'd like it to be. Finding the sweet spot is difficult (and it may change when you are coding just for yourself and when there is a larger audience). In order to find a good compromise, it is always interesting to explore all the possibilities in both directions. We have code with many safety measures, extensive comments and visual clues and we have code like this and, in contradiction with every theory, the terse style is doing quite well in terms of bugs and programmer efficiency. Why? Is that a coincidence? Could we have the best of both worlds? I do not say you should use this style for your projects, you don't even have to like it a little bit, but criticizing it because of its disadvantages without trying to understand its advantages is not a very productive point of view, in my opinion.

tluyben2 8y ago

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

Thank you for saving me the trouble of having to write the same thing. We programmers often seem to forget that we spend far, far more time reading code than writing it, therefore readability should be a (if not the) primary consideration when engineering it. That said, I do understand where Whitney's terseness impetus comes from: I have always lamented how little of my code will fit on the screen, with the number of vertical lines being the limiting factor; that is precisely why my taskbar is on the left-hand-side. (And don't get me started on monitors designed for watching wide-screen movies -- 1600x1200 FTW!) As such, I can't really fault his intention as much as his execution, and I feel that ultimately the solution to his (really, our) problem is that all our code (not just his) needs an IDE that can expand such terse definitions as per the current programmer's preferred style. This has been my perspective for many years, especially after wrangling various SQL dialects and the mostly awful formatting preferences of my peers. As I see it, the ideal solution is to store all code files as its token stream and have a default format that can be customized by each programmer in the IDE. As a result, each program will be stored as its pure content (which would help with version control (so long as whitespace is ignored)) AND each programmer would get to work with their preferred perspective. Of course the problem with this methodology is that the tokenizer and formatter better be flawless or you're f*ed, not to mention the fact that there are various IDEs that people like to work with.