He has a lot of really good blog posts and software toys on his site and on itch. I recommend looking through them. He also has a web comic that's pretty good, but he hasn't updated it in a while.
I'd also recommend checking out J, which isn't a recent development, but has the best syntax out of all array languages, has the best development environments, is the easiest to learn (it has a way to learn it built into the language itself!), and is the only one that treats making GUIs as a first-class feature (and, also, critically, is not proprietary, unlike Dyalog):
https://jsoftware.com (Has so many previous discussions I just recommend using HN search to find them.)
The chat is biased in favor of Dyalog APL, but a lot of the modern additions Dyalog has made to the language make it (in my opinion) worse as a notation, so ideally don't let it turn you off of the concept of array languages entirely if Dyalog doesn't "click" with you.
If you haven't already, you should also check out Notation as a Tool of Thought, a paper so good it won Iverson the Turing Award:
Dyalog clicks a lot more than J; "the best syntax"? "Easiest to learn"? Can you expand more on these positions?
And "a lot of the modern additions Dyalog has made to the language make it (in my opinion) worse as a notation" this one. I don't know when you mean modern but as a casual user, {} functions, trains, nest ⊆, rank adjustment ⍤ (like J), seem to make things more convenient?
Yes, absolutely. By a long shot. For starters, J can actually be parsed. (k can also be parsed, for what it's worth.)
"Easiest to learn"?
Spend ten minutes using J's built-in Labs feature. Or read J for C Programmers (also ships with the language), if you come from a non-array background. Iverson was able to teach this stuff to public school children in no time at all; modern array languages seem to deliberately make themselves obtuse to outside observers. APL was doomed to obscurity because the people making it decided to please existing customers rather than try and make it approachable.
I don't know when you mean modern
Pretty much every APL2 feature and everything that came after it that they didn't borrow from J.
While J has English control statements, they generally aren't used, but nearly every time I come across something written in Dyalog APL it's full of :If :EndIf and all sorts of atrocious English words which mock the ideal of a better notation than ALGOL.
Don't know where you got that one. J source can't even be tokenized except during execution!
NB. Compute n from reading a file of something
n : 0
Is this the source of a function, or a string?
)
Besides that, J has the same contextful issues as APL with regards to the value of variables determining how the syntax fits together. It's missing a few dark corners like niladic functions, but these are small differences; it's still fundamentally unparseable.
Regarding that, I am surprised that a 'more limited APL' lacking this ambiguity and opening the way to easy compilation never appeared (to my knowledge). I essentially use J for data wrangling and pretty much never use the metaprogramming features of the language (". and the like). An 'APL NumPy' would be quite nice, IMO.
K can be parsed. Even Q (the English version of K) can be parsed if you consider the prelude a part of the language (rather than part of the runtime environment).
An area that's still pretty different between J and APL (IMO) is that ⋄ makes APL much easier for procedural programming while J is easier for functional code. As a result, I (a journeyman in J and beginner in APL) tend to procedural much more in APL. I also get this impression from APLcart where ⋄ and ← are not at all uncommon. Of course, you can do that with J also using [x=. A second area of difference is that J is arguably more math-oriented, which is ironic considering the origins of APL, but I mean look at the primitives! J's 'higher-math' primitives are really useful for preparing datasets.
Also, I'm mainly doing preparatory data wrangling with J (i.e. quick&dirty work) and not having to activate the APL keys everytime is a nice feature. The ability to write a simple #! script and dispensing with the 'APL machine' of workspaces also counts (a feature that just appeared in APL). As a data wrangler though, the true killer feature of J is Jd, the integrated columnar store. Of course you can mmap through it all in APL, but having a completely integrated solution does the trick for me! Actually, I find the concept of 'fetch your data SQLish and model it with J' such a good idea that I'm playing with the idea of extending the concept to the Racket data science world (which is mostly non-existant) :-)
So if you're doing serious programming as done in Fortune 500 companies I'm pretty sure APL wins due to consistency and tooling integration, but for one-off work J is a killer!
The SE chat is really worth lurking if you're at all curious about APL; nearly everyone who has written a publicly-available array language implementation who isn't dead or over sixty is active on it.
I can't for the life of me find it again, but there was a youtube talk an hn user posted in a thread about array based languages a few weeks ago that basically showed a non-turing complete but still powerful array processing language based on Iverson and APL. I think it was developed specifically with streaming in mind. It was a really cool DSL that showed how much you can do without iterating over arrays.
It really kills me that I didn't save that talk. If I find it, I'll try to remember to update this comment with a link. It was kind of slick though.
As a Fortran programmer, I found his comments on "Evolution, not Revolution" to be interesting, including his argument for retaining 1-based arrays :).
Iverson's original APL was a notation for doing linear algebra. To make it a general purpose programming language, it had to be extended significantly. As a result, each commercial flavor of APL is rather different. I found APLX the easiest to understand and APL+Win the hardest, with Dyalog somewhere in between. APLX was a commercial product but is now free and is hosted on the Dyalog site. Another good one to start with is IBM's APL2. The demo version is full featured but time limited. It looks old, but has a well designed interface and good learning materials.
I love this: "it is my very strong conviction that making breaking changes would violate the trust that exists between Dyalog and its customers, and I would personally consider it to be unethical."
I do not actually have a personal need for APL or Dyalog's product, but nowadays it is pretty refreshing to see somebody who seems to deeply care about backwards compatibility.
Serious question, are people still using this language (APL) for anything serious? Or is it just a hobby language at this point. I notice that Dyalog sells commercial runtimes for about $2500 a year for Unix, so there must be someone.
Morten Kromberg (big guy at Dyalog; coincidentally, author of the post we're discussing) in "justifying" why Dyalog isn't libre, just a few days ago: There is little risk of the demise of Dyalog APL any time soon. Our customers run businesses that are based on Dyalog APL with a combined annual turnover in excess of a billion euros/dollars.
There are a few other companies with proprietary APL implementations that are also getting by really well.
k, which is pretty similar, is even more of a money-maker than Dyalog APL, having been responsible for a company worth a billion or more (Kx) and an entirely different company that also seems to be doing pretty well.
J also is used somewhat commonly, though less, and its users seem to be doing more than well, too (my current employer and most of my previous employers have been J shops, and none of them have gone under yet. I think a couple of them had record-breaking years in 2020). J is also free, libre software, so instead of paying for a Dyalog or K license, you should really just use it (or ngn/k, if k is more your thing).
It is an array language, an image is worth a thousand words, and an array[3][2][500] is a square image.
It'd be fun to tinker with visual effects of an APL function, and fun is a great way to fuel learning?