4 ms·

Your point 5 is completely wrong. 'The process of coding something into APL's idiosyncratic logography can only happen after the idea is already clear by other

Your point 5 is completely wrong. 'The process of coding something into APL's idiosyncratic logography can only happen after the idea is already clear by other means.' In fact, often I will write something in APL before translating it to other languages, not the other way round. When I was a beginner, I did translate things as I hadn't learned to properly 'think' in APL yet. Perhaps you have tried it, and not got past that initial barrier? In which case, my advice would be to stick with it for a bit. 'And virtually no one finds themselves understanding an algorithm via APL code which they did not already understand via more accessible languages or pseudo-code.' is also untrue. An example of a time APL like notation has helped me to understand an algorithm is Kadane's algorithm for a maximum subarray sum. There are probably hundreds of articles and videos out there explaining it, suggesting that it's probably something quite a few people find unintuitive. However, in k, an APL descendant, the entire algorithm is expressible as |/0(0|+)\ To anyone who knows APL/k this is instantly readable and intuitive. This was the first thing that really made it 'click' for me. Ok, APL hasn't been widely adopted and there are definitely some downsides and problems with it, but it's still useful and definitely not write-only.

lifthrasiir 5y ago
> However, in k, an APL descendant, the entire algorithm is expressible as |/0(0|+)\ The conclusion notwithstanding, an ability to concisely express the algorithm doesn't relate to an ability to actually understand it. Personally I found Kadane's algorithm intuitive as is and the concept of partial sum seems more important for the intuitive understanding of the algorithm. Array languages are surely benefited from built-in partial sum, but that'd be arguably same for any other language with readily accessible partial sum.
- civilized 5y ago
  > an ability to concisely express the algorithm doesn't relate to an ability to actually understand it. Exactly! Computationally, Kahane's algorithm is only a few simple steps. It's easy to write the steps down in a few lines of any language, and equally easy to understand what the individual steps are doing. The hard part about it isn't that it's too long and needs to be compressed into 8 symbols to be understood. The hard part is understanding why it is correct.
  - rak1507 5y ago
    Maybe conciseness isn't the only thing that determines understandability, but it's definitely highly related. (A 1 page proof is generally easier to read than a 100 page proof, no?) Kadane's algorithm was a simple example, and sure, it's not hard to understand in any language. My point was that the K version for me is the clearest and most obvious I've seen, and that understanding why it's correct is much easier starting from that than from the equivalent in say, Python or C++.
    - lifthrasiir 5y ago
      > A 1 page proof is generally easier to read than a 100 page proof, no? No. You can see the reason from information-theoretic aspect: highly compressed data is essentially indistinguishable from random data. Such data can only be recovered by a huge amount of prior information (in this case a decompressor) and any chance to recover it without that information is slim. Most human-readable data (not just code, but general language and so on) is highly redundant for this reason.
      - rak1507 5y ago
        No one's suggesting to compress code. I was just saying in general, shorter things tend to be clearer and easier to read. (as long as it's not overly 'golfed' or obfuscated)
        lifthrasiir 5y ago
        > as long as it's not overly 'golfed' or obfuscated This restriction is very subjective. For example APL and its descendants can be thought as golfed by default (indeed they tend to be far shorter in competitive golfing, see for example [1]). I'm not saying that they are not necessarily unusable! I just want to point out that being shorter doesn't generally mean much without further context. [1] https://code.golf/rankings/langs/all/bytes https://code.golf/rankings/langs/all/bytes
        5y ago

lifthrasiir 5y ago

> However, in k, an APL descendant, the entire algorithm is expressible as |/0(0|+)\ The conclusion notwithstanding, an ability to concisely express the algorithm doesn't relate to an ability to actually understand it. Personally I found Kadane's algorithm intuitive as is and the concept of partial sum seems more important for the intuitive understanding of the algorithm. Array languages are surely benefited from built-in partial sum, but that'd be arguably same for any other language with readily accessible partial sum.

civilized 5y ago
> an ability to concisely express the algorithm doesn't relate to an ability to actually understand it. Exactly! Computationally, Kahane's algorithm is only a few simple steps. It's easy to write the steps down in a few lines of any language, and equally easy to understand what the individual steps are doing. The hard part about it isn't that it's too long and needs to be compressed into 8 symbols to be understood. The hard part is understanding why it is correct.
- rak1507 5y ago
  Maybe conciseness isn't the only thing that determines understandability, but it's definitely highly related. (A 1 page proof is generally easier to read than a 100 page proof, no?) Kadane's algorithm was a simple example, and sure, it's not hard to understand in any language. My point was that the K version for me is the clearest and most obvious I've seen, and that understanding why it's correct is much easier starting from that than from the equivalent in say, Python or C++.
  - lifthrasiir 5y ago
    > A 1 page proof is generally easier to read than a 100 page proof, no? No. You can see the reason from information-theoretic aspect: highly compressed data is essentially indistinguishable from random data. Such data can only be recovered by a huge amount of prior information (in this case a decompressor) and any chance to recover it without that information is slim. Most human-readable data (not just code, but general language and so on) is highly redundant for this reason.
    - rak1507 5y ago
      No one's suggesting to compress code. I was just saying in general, shorter things tend to be clearer and easier to read. (as long as it's not overly 'golfed' or obfuscated)
      - lifthrasiir 5y ago
        > as long as it's not overly 'golfed' or obfuscated This restriction is very subjective. For example APL and its descendants can be thought as golfed by default (indeed they tend to be far shorter in competitive golfing, see for example [1]). I'm not saying that they are not necessarily unusable! I just want to point out that being shorter doesn't generally mean much without further context. [1] https://code.golf/rankings/langs/all/bytes https://code.golf/rankings/langs/all/bytes
        5y ago