> Its powerful array manipulation primitives can easily be brought forward into a language with modern syntax, and haven't they?

Kind of. The languages that one might expect to do this (Julia, R, NumPy) have picked out a few things from APL in an inconsistent way, leaving a lot as well. For example most are missing the generalization of prefix sum that APL calls "scan". So in [0], Conor was able to translate some code to every language in the APL family but not yet any outside of it. Another one, I don't think I've ever seen Replicate[1] outside the APL family. It's a generalization of filter to take an arbitrary count instead of 0 or 1 that's often useful if you know about it.

[0] https://github.com/codereport/array-language-comparisons/blo...

[1] https://mlochbaum.github.io/BQN/doc/replicate.html

Julia spells "scan" as "accumulate". I don't think we have something exactly like replicate out of the box, but it's a one-line function definition away:

     replicate(inds, v) = mapreduce(((i, n),) -> fill(v[i], n), vcat, enumerate(inds))

I agree with the spirit of your point though. Having operations like this as part of your 'alphabet' can be a really powerful thing. That's why I think APL is really well suited to being a domain specific language embedded in a language like julia. Shashi took a stab at this a few years ago, but it'd be nice to revive it: https://github.com/shashi/APL.jl

R has `rep` for replicate:

    rep(c("a", "b", "c", "d"), c(2, 1, 0, 2))
    c("a", "a", "b", "d", "d")

Replicate looks like numpy's repeat. For example

  np.repeat(list("abcd"), [2,1,0,2])

is equivalent to the first example in the link.

Ah, thank you! I'd tried to find this for implementing BQN in NumPy (never finished) and didn't. Maybe I thought it only worked with a scalar for the number of repetitions.

I can't make head or tails of the first links, so I'll leave experts to it. The second one, yeah, it's nice syntaxical sugar, but it can be replicated very easily (map + "constant list" + concatenate). And versions of it exist in many languages - even C# has SelectMany https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu...

All the good APL functions can be implemented easily (but please, they're just built-in functions, not syntactic sugar!). It's the selection of which functions to implement that makes it so much better for working with arrays.

"even C#" seems to imply you have less obscure examples than a function in a Linq package, is this the case? I admit I've never looked into Linq but I do see it come up in array language discussions sometimes. It's possible it has a more APL-like philosophy for a slightly different use case. The other difference is that APL uses a function on two arrays, which is nice because you can easily filter based on, say, the previous element.

EDIT: No, the C# function seems to only do the mapping and concatenation and doesn't even take a number of copies, that's really not the same.

Numpy has replicate (numpy.repeat).

Excel has SCAN.

APL derivatives (like q) seem to have a niche use in the finance industry for processing time series data. I've played around with J (another APL derivative) and it was interesting. I could see it being useful for certain types of problems. Probably hard to use it on a large team though since it's so hard to read.

In R I often use the data.table library and the style of programming that encourages feels similar to how J made me think.

This dismissal doesn't address any of the points in favor of brevity and economy Iverson brings up in "Notation as a Tool of Thought".

> modern syntax

is mostly awful.

I'm not from this era and I love APL to bits. My brain is wired for extreme concision. Enterprise Java damaged my brain while APL and similar revives it.

It was from an era of 110 baud teletypes. Thus, brevity was of extreme importance.

Brevity is more important today.

The more thoughts you can fit on a page, the less taxing it is for your working memory.

We try to use abstraction - libraries, DSLs, even lowly functions - to tame ever more complex problems, but anyone who's had to debug a dependency of a dependency is painfully aware of the cost of leaky abstractions.

I had a problem in 2000-s when we needed to put some code into data files, and that code had to be short. So, when space was at premium, APL approach was rather convenient - even though it was already time of Skype and some video over the Internet.