APL could serve the niche as a write only language. Not for code to be maintained, but for one offs. Of course, those one offs inevitably become code to be maintained, so maybe this niche doesn’t really exist.

It would also be a phenomenal spreadsheet language. the terseness means we get more visible code per cell block, the default data types mesh well, and the numerical orientation of the language is ideal.

We already have regex for unmaintainable, read-only code.

regex isn't a programming language, it is a language for describing strings that can be recognized by finite automata.

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.

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

> 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/ in which enthusiasts from several different Iversonian Array languages talk about how array languages enable them to solve problems differently.

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

Offtopic, but I really dislike how so many information out there is the inaccesible format that is "podcasts".

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

> Just as much so as սուրճ or コーヒー or קפה.

But far less than the equivalent code in, say, Python, or C, or any other language. That's the point.

> What do you think makes podcasts inaccessible?

Lack of visible, searchable structure and the requirement of audio (in those that don't have transcripts, which is a lot of them) to get the information.

All episodes of the Arraycast have both transcripts and extensive show notes for background information for those who may not be array programmers. The challenge of delivering knowledge via an audio format is real, but use of transcripts makes it much more accessible.

Indeed, this podcast seems to do a decent job. It was more an off topic remark about how inaccesible podcasts usually are for actually finding information.

2_&{&/x!/:2_!x}'!R is very understandable to someone who knows K. (Or at least, the idea is, do you know what dialect it uses? Where's the code from?)

The (roughly) equivalent python is filter(lambda x:all(x%i>0 for i in range(2,x)),range(2,R)) - is this really that much better? (yes if you know python, no if you know k)

> (Or at least, the idea is, do you know what dialect it uses? Where's the code from?)

From Wikipedia page of K programming language https://en.wikipedia.org/wiki/K_(programming_language)

> filter(lambda x:all(x%i>0 for i in range(2,x)),range(2,R)) - is this really that much better?

You don't need to know Python. Filter is probably doing a filter, "lambda x: ... " looks like a lambda function, for looks like a loop... I am 100% sure that, without any language knowledge, the Python version is far more easy to understand.

Ah, that code was added to the wiki page in 2006 apparently. A modern version is basically the same anyway.

I will (maybe) agree that the python is easier to understand without any language knowledge - but that does not mean the K is not understandable. If you know K, it is understandable, and knowing a language seems like a pretty low bar for understanding it.

I mean, by the same measure, spaghetti code is not spaghetti code if it makes sense in your head. But we all understand that there are certain qualities of code that make it “spaghetti” or not independently of your understanding of it. Similarly there are features of languages (such as terseness, use of symbols, context-dependency

If you don’t know a language but are hoping to read it, for what purpose are you intending to read it? Is it a casual understanding? If you’re talking about maintaining the code it’s probably better to stipulate that people already know the language. If you want to maintain code in a language you don’t know, I’m not sure you’d be a great hire.

Unless you have perfect memory and perfect recall, it’s very possible you’ll forget what a certain symbol meant. Much harder to forget what the word “filter” means. Also much easier to recognize words than symbols where differences might be small.

It's really unlikely (imo impossible) you'll forget what a symbol means in APL or K etc if you program in it reasonably often. There aren't many symbols, and most of them are used pretty frequently. If you do forget, there's plenty of resources to jog your memory though. The Dyalog RIDE has a language bar at the top, and hovering over a symbol gives a brief description with examples. https://janiczek.github.io/tryapl-elm/ replicates this if you want to see for yourself. I disagree that it's easier to recognise words than symbols if there are small differences, the symbols are distinctive anyway so that's not really a real problem.

> It's really unlikely (imo impossible) you'll forget what a symbol means in APL or K etc if you program in it reasonably often.

Well, of course, if you’re always practicing the same thing you’re unlikely to forget it. That’s not always the case, though.

> the symbols are distinctive anyway so that's not really a real problem.

Really? From that toolbar alone I’m seeing empty circle vs slightly smaller empty circle, a lot of symbols with/without a dash or umlaut, dot and comma… seems pretty easy to get a lot of those confused or misread.

It seems like it might be easy to confuse things, but from experience, it isn't.

I feel like in general, you're making a lot of (fairly reasonable) assumptions about what programming in an array language is like, but they aren't really the case (as lots of other people have tried to explain). Without really trying it out, I'm not sure how someone could convince you otherwise, so there's a bit of an impasse.

I think you should listen to what people are saying and have said in the past though (https://news.ycombinator.com/item?id=33640275, https://news.ycombinator.com/item?id=22524918) and trust that for some people who do learn array languages, they do find it useful + productive, and a lot of the things you've raised are not issues in practice.

I have listened and to me it always seems to come down to “you make reasonable points but it’s not a problem for me so it’s not a problem”.

And I think there’s a lot of implicit bias when people who like APL say it’s perfectly readable. Given how readability hits you in the face first thing when you see APL and how it’s not a widely used language, only the people enthusiastic about it and willing to overlook the readability issues will end up learning it. Of course they don’t find issues in practice, if they had issues with that they’d have probably abandoned the language quickly.

> and trust that for some people who do learn array languages, they do find it useful + productive, and a lot of the things you've raised are not issues in practice.

I’m not saying it isn’t useful or productive. That’s not the discussion. The point is that they’re languages that they’re hard to use and hard to read. I don’t see how it’s such a controversial point.

For example, I like LaTeX a lot. I’ve done quite a lot of things with it, it’s been very useful and I’ve been very productive with it. I have no problem reading that code. But the fact that I have no problems doesn’t mean there aren’t actual problems with LaTeX. LaTeX will always be hard to read and quite a bit messy no matter how used I get to it.

Yes - the first thing you notice when you see APL is 'this looks weird'. Most people then assume 'this is complicated, hard to read, and hard to use', and move on with their lives. Some people decide to learn it anyway, and quickly (within under a day) realise it is actually simple, readable, and easy to use!

It's not like some people are magically born with the ability to read APL (or anything else), and learning it isn't a matter of 'overlooking the readability issues', but rather realising the 'readability issues' are a false assumption. There's not 'bias', there's just experience.

That is why "they’re hard to use and hard to read" is 'controversial', because it is just not true.

> Some people decide to learn it anyway, and quickly (within under a day) realise it is actually simple, readable, and easy to use!

Do you think all people who decide to learn it anyway end up with the same conclusions?

> That is why "they’re hard to use and hard to read" is 'controversial', because it is just not true.

So things like symbols having different meanings depending on number of arguments, prefix notation making the arguments of functions/operators stand out less, making it reading right-to-left (which is different from what you usually read - that brings the fun question of whether APL is left-to-right in Arabic countries), or having to know extra symbols that aren't used in other contexts... All of those things are not real?

I come back to the LaTeX example because to me that's very similar. I get when you say "I don't find APL hard to read/understand/work with" because I feel the same with LaTeX (even though it's not as obscure and "alien-looking" as APL is). I write slides in LaTeX faster and better than what I could do with Powerpoint. But that doesn't deny that there are a lot of things in LaTeX that make things harder, even when those are part of the core and when removing them would mean removing good things about the language too.

I think all people who try to learn APL for more than about 5 minutes end up realising most of their assumptions were completely wrong. Maybe they don't reach exactly the same conclusions (a lot of people do), but they reach similar ones.

> So things like <APL things> are not real?

They are real, but they are not issues for anyone who has tried APL at all.

Advent of code is starting soon, I'd recommend that you pick an array language and give the first couple of problems a go in it - even if you don't like it, at least it would save you from making yet more uninformed comments next time an array language article is on HN (and save array language programmers worldwide the pain of reading them).

Um, yeah. Knowing a language generally involves putting time into learning and the benefit is not forgetting stuff. You seem to not want to own the fact that your entire impression is predicated on it being not practical for someone not interested in investing any time into it. But I’m not sure that the input from such people is ever valuable.

APL is pretty big on immutability and pure functions too. Arrays are immutable, period, and the link below has John Scholes talking about the advantages of declarative programming back in 2005. And, uh, yes, APL tells you where the error is when you get one. It's pretty obvious you've bounced off due to a surface-level dislike for the syntax and are guessing about any other features it may have.

https://www.dyalog.com/uploads/documents/Papers/declarative_...

> It's pretty obvious you've bounced off due to a surface-level dislike for the syntax and are guessing about any other features it may have.

I'm not saying APL doesn't have those features. I'm making examples of languages that have a clear value proposition. If APL is big on immutability and pure functions, then why use APL vs, say, Haskell or Clojure? Same with the "where is the error thing", I was explaining why maintenance isn't just a "depends on who maintains it" thing, in fact the example languages were assembly and Python, nothing to do with APL.

I've talked to plenty of people whose eyes light up when you tell them 5 + 1 2 3 just works in the language. What you're saying is that you didn't find APL's value proposition attractive, and this is a fact about you, not APL.

> I've talked to plenty of people whose eyes light up when you tell them 5 + 1 2 3 just works in the language.

This is literally "people who like it say they like it". It's like saying that the value proposition of Python is having list comprehension, when that's just syntactic sugar.

And no, it's not just me, you just have to take a look at the comments or even the OP. The only point being made is that it has very powerful array programming primitives, but those functions can be easily brought to other languages (and indeed a lot of them have those primitives).

> It's easier to read "mod(1, 3)" than "1 % 3".

Why is it? You're assuming that I know what "mod" means, what the parens and comma signify (and perhaps what the lack of space in mod( but the presense of space after the comma indicate). If I didn't know those thing, they aren't at all readable and there's no way to guess. Wouldn't it be "1 modulo 3" for readability? Look at beginners in various languages posting on the internet asking what the different parens, braces and brackets do and when to use them. And then you're assuming that I don't know %, which because it's so common in C-like languages, I do, but if I didn't the glyph looks like division.

NB. that mod() implies modulus and % is remainder, and "rem" is even worse because it looks like BASIC's "remark" comment word. https://stackoverflow.com/questions/13683563/whats-the-diffe...

It's easier to read "(AA|AB)([0-9A-F]{7,10})ZZ" than to write that regex in a flowchart of if/else branches and string and state manipulation. And easier to verify it's correct. Just because you can write unreadably hideously long regexes doesn't mean regexes should be shunned for unreadability, for a range of patterns they are usable, convenient and powerful.

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

I'm not sure they have one in the large scale; I would like one as a rectangular-pattern-regex inside another language or shell because of the notation, and not in the sense that "you can do the same thing with numpy". I can write text search in Java, I'd rather use grep.

I say the same thing about Rust and am regularly told to shut up.

don't you. think you can become better at it after some practice? let's compare that with mathematics notation or whatever... APL has less symbols than java's String methods.

> arcane symbols

I have never been able to shake the impression that APL is a troll language, like INTERCAL or brainfuck, except that part of the 'joke' is to insist that there's no joke. APL makes me feel gaslit.

The thing is, APL was originally designed as programming notation. It was used by Kenneth E. Iverson to discuss programming problems on blackboards with his students for years before it had an actual implementation.

So it has much more in common with math notation as a result, which is why the focus is on expressing yourself tersely with symbols. Also: nobody has to worry about special keyboards with symbols when writing those symbols with chalk on a blackboard, right? So the medium shaped the mode of communication.

I wonder what it would be like to learn programming that way, without using a physical computer. Maybe it would actually be a lot more pleasant for working through programming problems together? Mathematicians seem to be doing just fine working out their problems together on the blackboard with their notation after all.

I spent a fair bit of time with APL back in the 80s on IBM 3090 mainframe and a 3278 APL terminal and I have to say that if you've got an "APL shaped problem" and some familiarity with the language, it's easy to read and not so hard to maintain. Learning curve is a bit steep, though...