These are written in a generally basic and clean style (avoiding tacit programming which is sometimes considered hard to understand, e.g. function {s↑⍺↓⍵} instead of the train (s↑↓)). They're nice to read and I'd have no trouble maintaining them. You just don't know the language.
conv looks like the hardest. s←1+(⍴⍵)-⍴⍺ is the result shape, number of subarrays with the length of ⍺ that will fit in ⍵ in each dimension. Looks like (⍳⍴⍺){s↑⍺↓⍵}¨⊂⍵ is missing the ¨; the inner function s↑⍺↓⍵ drops ⍺ elements (left argument) and then takes the first s, so it gets a length-s window of ⍵. This is called on each possible index into ⍺, together with the whole of ⍵, so it ends up getting all such windows. Presumably s is expected to be larger than ⍴⍺ so this is the more efficient way to slice things. ⊃+/,⍺× multiplies by ⍺ and sums, ravelling with , before applying +/ to collapse the dimensions and sum them all at once. Each element is an array of shape s, so summing them gives a result of shape s. There you go, multidimensional convolution!
I'd bet money that I could figure out what this code is doing easier than the equivalent in Python, which is my daily driver. You just need to look up the symbols and piece it together. Yes, that takes an extra step, but so did learning any new language. Also, I can see all of this in one spot.
The value of being able to see the entire implementation of a nontrivial program at once cannot be overstated. This is the real magic of APLs: no unnecessary abstraction, boilerplate, or structural fluff, just algorithms composed from general high-level building-blocks.
The right level of abstraction is key. If your problem maps neatly to the primitives offered by APL, then the code will be readable idiomatic APL. If, however, they don’t, and you are using the APL abstractions in ways they were not intended to, and you are building new abstractions on top of them, then you’ll need to be a skilled programmer to keep it readable.
Hard disagree. I wrote a YAML parser in APL[0], set it aside for 8 months, and then one day decided to read through it while getting a haircut. I can happily report that the full 22 lines (with zero library deps) were very grokkable. In fact, I even found a bug and now have several ideas for a rearchitecture I'd like to work on.
APL just looks unfamiliar. Don't confuse that with unreadability. IMHO, the ergonomics for expressing and communicating high-level specifications just blows other languages out of the water. And those specifications also happen to also be executable implementations with leading-edge performance to boot.
Admittedly, though, the learning curve is painfully steep. I think it's worth it though.
No, not that at all. It is more a reflection of APL’s extreme density. C-derivatives tend to devolve into ASCII-salad, which is no better.
Also, with APL, the code for something that can be expressed in linear algebra is reasonably natural, but when APL gets used to code other things it can be hard to reverse out what the author was thinking when they found a linear algebra expression of a problem for which that is not a natural mapping.
What these all have in common is that the computer wasn't that clever (yet) compared to humans, so it was worth learning a cryptic but efficient (in terms of code size, or execution speed) language. Or maybe these "line noise" languages were just fashionable.
Now, JIT-ing something eminently readable is essentially free, so there is no more point in these old things (I don't personally use Matlab, but all the theory people at work do, and it seems to be the spiritual successor to APL).
I'm here reasonably often but have missed prior posts. I love these old school (literal in this case!) presentations. Information density is off the charts.
Apparently this used to be a common thing, groff has a feature to output bold text for TTY devices by backspacing and re-printing each character twice.
You can get underlined text in a similar way using backpace and underscore.
It doesn't work out of the box on terminal emulators, but less(1) does this rendering for man pages, etc.
