2 ms·

> Maybe conciseness isn't the only thing that determines understandability, but it's definitely highly related Making something short is different from making

> 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.
  - rak1507 5y ago
    That's a nice subtle insult there - I can obviously understand what a for loop does. You can resort to explicit loops in array languages anyway. I doubt the lack of looping mechanisms is why they've been as successful in general purpose programming, probably more to do with unfamiliarity + historical lack of open source implementations I would guess.
    - civilized 5y ago
      It's not meant to be an insult, I'm trying to reflect what you're saying. You seem to be saying it's much harder to understand the algorithm in the for loop formulation. That's mind-blowing to me. I feel like it's a very small difference, and the same concept comes across in both formulations, although I agree it's a bit nicer in the K version. If that's how your brain works, and how a lot of APL lovers' brains work, I definitely get how APL would be strongly preferable to folks like yourself. To each his own, maybe. I think there can be a lot of diversity in how smart people's brains work, so it's really not meant to be insulting or condescending. It's hard for me to understand but I can accept it if that's how it is. We all want our languages to solve problems with concise, easy-to-understand, nice-looking code, but the considerations that go into that can perhaps be very different by individual.
      - rak1507 5y ago
        Ok, my bad, I misinterpreted your comment a bit, sorry about that.

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.
- rak1507 5y ago
  That's a nice subtle insult there - I can obviously understand what a for loop does. You can resort to explicit loops in array languages anyway. I doubt the lack of looping mechanisms is why they've been as successful in general purpose programming, probably more to do with unfamiliarity + historical lack of open source implementations I would guess.
  - civilized 5y ago
    It's not meant to be an insult, I'm trying to reflect what you're saying. You seem to be saying it's much harder to understand the algorithm in the for loop formulation. That's mind-blowing to me. I feel like it's a very small difference, and the same concept comes across in both formulations, although I agree it's a bit nicer in the K version. If that's how your brain works, and how a lot of APL lovers' brains work, I definitely get how APL would be strongly preferable to folks like yourself. To each his own, maybe. I think there can be a lot of diversity in how smart people's brains work, so it's really not meant to be insulting or condescending. It's hard for me to understand but I can accept it if that's how it is. We all want our languages to solve problems with concise, easy-to-understand, nice-looking code, but the considerations that go into that can perhaps be very different by individual.
    - rak1507 5y ago
      Ok, my bad, I misinterpreted your comment a bit, sorry about that.