3 ms·

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 dist

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.

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.