5 ms·

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

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
    - rak1507 5y ago
      They can definitely be much shorter than other languages in golfing, no doubt about that. I wouldn't say they're golfed by default though really.
civilized 5y ago
> Maybe conciseness isn't the only thing that determines understandability, but it's definitely highly related Making something short is different from making it concise. The Python version is perfectly concise. There are no distractions or boilerplate. Making it shorter doesn't make it more concise beyond that point. > 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++. I think this very unlikely to be correct. The K and the Python are saying the same thing. Understanding why it works is the same problem from either starting point. Now, I will admit that it's helpful to explicitly express "cumulative sum which is floored at zero" in your implementation, and K pushes you towards that solution, while Python and other languages don't force you into looking at it that way. But that's more about alignment of the most transparent formulation with the language primitives, than it is about shortness.
- rak1507 5y ago
  Generally in all imperative solutions I've seen, there are more 'moving parts', manual updating a maximum variable, explicit iteration etc, these to me are distractions and boilerplate compared to a functional/array lang solution. Sure, they're saying the 'same thing', but that doesn't mean both ways are equally as understandable. They're definitely not to me, and probably others too (who know array langs).
  - civilized 5y ago
    Maybe brains just work differently here. I agree that it's nice to have array primitives like sum(x) and cumsum(x) instead of just for loops, and you can indeed have those in most languages. And it's very cool that APL type languages can concisely express a wider range of array primitives than other languages. But... in this Kadane situation, I really, really don't find that the for loop makes the difference between understanding it and not understanding it. That's mind-blowing to me, quite honestly. More generally, based on my MATLAB experience, I also find that expressing everything in array primitives clearly, clearly doesn't scale beyond a certain level of complexity, and it's very important to have the ability to resort to for loops beyond that. You can do a lot in the array processing paradigm but it quickly becomes obfuscated if the problem doesn't fit the primitives well. The array paradigm can really be a straitjacket, and this helps to explain why APL and related languages have been successful in e.g. financial time series computation, where those primitives are well-suited, but have not gained traction in general-purpose programming.

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
  - rak1507 5y ago
    They can definitely be much shorter than other languages in golfing, no doubt about that. I wouldn't say they're golfed by default though really.

civilized 5y ago

> Maybe conciseness isn't the only thing that determines understandability, but it's definitely highly related Making something short is different from making it concise. The Python version is perfectly concise. There are no distractions or boilerplate. Making it shorter doesn't make it more concise beyond that point. > 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++. I think this very unlikely to be correct. The K and the Python are saying the same thing. Understanding why it works is the same problem from either starting point. Now, I will admit that it's helpful to explicitly express "cumulative sum which is floored at zero" in your implementation, and K pushes you towards that solution, while Python and other languages don't force you into looking at it that way. But that's more about alignment of the most transparent formulation with the language primitives, than it is about shortness.

rak1507 5y ago
Generally in all imperative solutions I've seen, there are more 'moving parts', manual updating a maximum variable, explicit iteration etc, these to me are distractions and boilerplate compared to a functional/array lang solution. Sure, they're saying the 'same thing', but that doesn't mean both ways are equally as understandable. They're definitely not to me, and probably others too (who know array langs).
- civilized 5y ago
  Maybe brains just work differently here. I agree that it's nice to have array primitives like sum(x) and cumsum(x) instead of just for loops, and you can indeed have those in most languages. And it's very cool that APL type languages can concisely express a wider range of array primitives than other languages. But... in this Kadane situation, I really, really don't find that the for loop makes the difference between understanding it and not understanding it. That's mind-blowing to me, quite honestly. More generally, based on my MATLAB experience, I also find that expressing everything in array primitives clearly, clearly doesn't scale beyond a certain level of complexity, and it's very important to have the ability to resort to for loops beyond that. You can do a lot in the array processing paradigm but it quickly becomes obfuscated if the problem doesn't fit the primitives well. The array paradigm can really be a straitjacket, and this helps to explain why APL and related languages have been successful in e.g. financial time series computation, where those primitives are well-suited, but have not gained traction in general-purpose programming.