Comment by rak1507 | Hacker News Reader

Comment by rak1507 | Hacker News Reader

Parent Full thread

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.

> 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.

> 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.

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++.

> 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.

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)

> 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

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.

> 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.

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).

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.

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.

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.

Ok, my bad, I misinterpreted your comment a bit, sorry about that.

Reply on news.ycombinator.com