5 ms·
APL (and probably many languages in the Iversonian family) are more geared towards expressiveness, although terseness plays a large part of the language design.
by memorable 4y ago
APL (and probably many languages in the Iversonian family) are more geared towards expressiveness, although terseness plays a large part of the language design.
Also, once you understand the rules of these languages when parsing expressions (which is always right-to-left unless the case of a parenthesis) and all the symbols, readability become less of a problem.
As for maintainability, well, it kinda depends on you and whoever is going to maintain it.
I do agree that the arcane symbols of APL is a minus, though. Which is why languages like J, K and Q are born: to make APL ASCII-friendly.
Generally speaking, this seems to me like a comment from someone who doesn't give APL more than a cursory look. And if that relates to you, please, try APL, or any other languages in the family, just even once. You _may_ change your view about it.
- gjulianm 4y ago> Also, once you understand the rules of these languages when parsing expressions (which is always right-to-left unless the case of a parenthesis) and all the symbols, readability become less of a problem. This is a very limited view about readability. Of course, once you get used to anything, it is more readable. But if most programming languages have moved away from symbols other than the standard ones precisely because symbols are a readability problem (even some languages like Python have and/or/not instead of &&/||/!, and those are pretty standard). It's easier to read "mod(1, 3)" than "1 % 3". > As for maintainability, well, it kinda depends on you and whoever is going to maintain it. Again, putting these issues on the people is missing the point of the discussion. Does the language incentivize the creation of easily understandable, fixable functions? Is it easy to detect and fix bugs? For example, assembly is harder to maintain than Python because a bug in assembly is hard to find, possibly complicated to fix because coding in assembly isn't really that easy... on the other hand, a bug in Python probably shows up as an exception even, that tells you in which line of code it's crashing. > Generally speaking, this seems to me like a comment from someone who doesn't give APL more than a cursory look. And if that relates to you, please, try APL, or any other languages in the family, just even once. You _may_ change your view about it. Honestly, J/K/Q/APL make it really hard to give them more than a cursory look. And the problem is that I've never seen a really good argument to do more than that. For example, first time I saw Haskell, it was hard to pick up, but at least I saw value in the proposition of immutability, pure functions, etc. Not for all use cases, but at least for some. I haven't given Go more than a cursory look but, again, the idea of a compiled language with GC and memory safety looks cool. I've never seen the value proposition of these family of languages other than "people who like them say they like them", and by the looks of the comments I don't seem to be the only one.
- schwartzworld 4y ago> because symbols are a readability problem I think the difficulty of this is overstated. My kids are learning to read Armenian and English at the same time. 38 Armenian letters + 26 English ones, each with upper and lowercase versions. If a 6 year old can do it, you can learn a couple of new glyphs when programming. > Honestly, J/K/Q/APL make it really hard to give them more than a cursory look. And the problem is that I've never seen a really good argument to do more than that. It's a little disingenuous to claim that something you've never tried to do is too hard and has no value. > Does the language incentivize the creation of easily understandable, fixable functions? Lol, that is literally the point of them. I've been really enjoying https://www.arraycast.com/ https://www.arraycast.com/ in which enthusiasts from several different Iversonian Array languages talk about how array languages enable them to solve problems differently.
- gjulianm 4y ago> I think the difficulty of this is overstated. I have my degree in mathematics and I've used my fair share of symbols. It's been a consistent finding in articles, books, classes and peer conversations that symbols are not that optimal. Inventing new symbols, or overusing them is frowned upon because they don't really make things easier to understand and can sometimes be a cause of confusion. > It's a little disingenuous to claim that something you've never tried to do is too hard and has no value. I'm not saying "it has no value", I'm saying that I've never seen a good argument to actually invest time in them. As I explained, other languages have clear value propositions. In J/K/Q/APL , the value proposition tends to be a vague "I like it" from people who like it. > Lol, that is literally the point of them Yes, 2_&{&/x!/:2_!x}'!R is very understandable. > I've been really enjoying https://www.arraycast.com/ https://www.arraycast.com/ Offtopic, but I really dislike how so many information out there is the inaccesible format that is "podcasts".
- schwartzworld 4y ago> Yes, 2_&{&/x!/:2_!x}'!R is very understandable. Just as much so as սուրճ or コーヒー or קפה. > Offtopic, but I really dislike how so many information out there is the inaccesible format that is "podcasts". I can't think of a better format for what they are trying to do with the ArrayCast. It's not teaching people array programming, just a conversation between people who are proficient in it. What do you think makes podcasts inaccessible? For example, I often recommend https://soundcloud.com/lambda-cast https://soundcloud.com/lambda-cast to developers looking to understand functional programming. The conversational approach works well because some of the panelists are being taught these concepts for the first time and they ask great questions. There are plenty of books and articles on the subject, but conversational audio is a wonderful supplement.