I like APL (and k/j). Problem is, outside trading (and even there it's a niche), it is just not popular enough. This also because most people dismiss it as line noise / write only programming language; that's usually only people who never used it or used it briefly saying that. But it's hard to promote anything that has a reputation like that.
What is a fairly interesting observation (more people have made it, including Arthur Whitney); being able to reason about a program for which you can see all the code on one A4 without having to clickthrough into functions, search, browse through files, classes or even having to scroll is incredibly powerful. All you need is the cheatsheet (provided in your article) (which you know by heart in no time flat) and the program, which, often fits on 1 A4 or less. Modern example of that would be Aaron Hsu his 17 LoC parallel APL compiler[0] (from his thesis).
The reason you give (write only programming language) is indeed ONE of the reasons people may give when discussing about array-languages, and it is actually a serious reason to consider. Having spent much time on it as well as on J, I hope not being part of those "only people who never used it or used it briefly" because I would also add another reason, more important to me.
APL emphasizes some "formal external beauty" (of code) over the true beauty of an algorithm. Of course you can do such or such thing in 2½ characters of APL code rather than 60 boring lines of whatever language you want but it is generally full of unneeded hidden loops (or looping uselessly on whole parts of arrays when only a small part is required). Actual complexity of these "elegant" APL solutions is generaly insane.
On the other hand, the J language has a set of some "optimized" idioms -if I remember correctly. Not sure the thing is really better: "write it that way by pretending you are following the array-way-of-life; of course it would be insane to actually do it that way, but my engine will detect the very specific thing you want to do and will use a state-of-the-art algorithm for that purpose". Not sure it is a good thing because the task becomes over complicated: knowing the true (boring) algorithm, knowing the specific array-syntax encoding that algorithm, which falls back to looking in some "list" of what is optimized or not.
While I agree these languages are fascinating to think about computing, learn new things, etc. I finally went to more or less agree with Dijkstra (not the worst reference?) about these languages being "a mistake, carried through to perfection".
What is wrong about writing well commented, well indented, 30 lines of code if I can implement the exact algorithm that way?
> This also because most people dismiss it as line noise / write only programming language
Not so. Anyone who says these things simply does not know APL. It's like saying musical notation is write-only. Sure, if you don't know it reading the darn thing is excruciating. Yet, if you do, you can see music on the page.
What APL is not is a low-skill, low-knowledge language. A casual glance at the language isn't enough to know it. Just as you can't internalize musical notation without dedication, work and experience.
Back in the '80's I used APL professionally for about a decade. From that context, it reads like music. To this day I can read it just fine (though not as quickly). Interestingly enough the same is the case musical notation, which I could read without thinking twenty years ago, when I was studying and playing classical guitar and piano with great regularity.
That said, I would not recommend anyone get serious about APL today. Study with some degree of dedication? Yes, I think that would be of value. Real projects? No. Definitely not.
If that means "you don't get much more than what C offers", then I'll take that as a no. I18N, Unicode, Regex, built-in string manipulation functions, character set conversions and efficient data structures are table stakes at this point.
No, it’s quite a bit more than C offers, which has a paltry twenty-eight “operators”, none of which “work” on arrays. Most of the libraries in C and C-like languages have huge libraries because getting those twenty-eight operators to do anything can be a lot of work if you don’t think about it much.
In contrast, Iverson has more than 50 excellent operators, sensibly extended to arrays. Not all APLish languages have all the operators, but the choice about what they do have typically considers how all of Iversons operators can be/are used and how/when they can be implemented in terms of each other. This is largely a matter of taste.
And better symbols means better ideas. Some things are just more obvious in APL. And once you see it, you can take it with you.
When using C, I don’t typically use the C library, or libraries for any of those things you mentioned, because they just aren’t that complicated once you have seen APLish solutions to those problems. And that’s a good thing because less code means less bugs.
So if I understand you right, APL treats strings as arrays of whatever. This makes sense and isn't particularly hard to understand. Is there a way to treat Unicode strings as arrays of graphemes, instead of bytes or codepoints?
It does code points, not graphemes. Graphemes are a pretty niche thing, I believe? Raku's the only language I've heard of having built-in support rather than using a library.
APL is very decent at string manipulation. I could try to explain why, but I am afraid that you'll have to see for yourself to understand why what you wrote is both true and not very applicable to APL.
This is indeed part of what I meant to see before in this thread; it is very hard to convince people, who are kind of biased already by the syntax and the 'old age' of the language, to just try it out for a while. It's the same issue with Lisp/Scheme; if you do wrestle through Common Lisp: A Gentle Introduction and/or SICP, you'll see things in a different light, probably forever and for the better. But it takes (a lot of) effort and if you are biased against something from the start, that's not going to stimulate you much.
What is a fairly interesting observation (more people have made it, including Arthur Whitney); being able to reason about a program for which you can see all the code on one A4 without having to clickthrough into functions, search, browse through files, classes or even having to scroll is incredibly powerful. All you need is the cheatsheet (provided in your article) (which you know by heart in no time flat) and the program, which, often fits on 1 A4 or less. Modern example of that would be Aaron Hsu his 17 LoC parallel APL compiler[0] (from his thesis).
[0] https://www.bonfire.com/co-dfns-thesis-edition/