These two expression doesn’t carry the same level of information. At best the first, without additional contextual information can only be interpreted as into "The surface of two square equals to a third", or more directely "a·squared plus b·squared gives c·squared".
APL expressions, just like mathematical formula, don't just float alone in a void in practice. They exist within a context, some problem domain, surrounding code and/or equations, etc. Just how the equation "a^2 + b^2 = c^2" can encode equivalence relations between different structures, depending on context, APL expressions take on interesting, semantically useful meanings when applied to a particular problem domains.
The reason I call this a strong point of APL is that, in "normal" languages we tend to re-encode that extra domain-specific information all over the place at the micro level—within function names, type signatures, and more pertinently in the abstractions we make. APL enables (but doesn't demand) us to let that information manifest directly at the macro level, without erasing the unused potential semantics of the raw algebraic expression.
This is something that practicing mathematicians get intuitively, I believe. Take category theory, for instance, where commutative diagrams in their most abstract form really are Abstract Nonsense™, but their power comes from instantiating them into specific categories, without having to erase the information about the fact that the same diagram also applies within other categories. That kind of thing really tickles the natural abilities of human pattern matching in a productive way.
> in "normal" languages we tend to re-encode that extra domain-specific information all over the place at the micro level—within function names, type signatures, and more pertinently in the abstractions we make.
But that's good! It means there are less possible sources of truth, less things to update when something changes, and less context switching.
This doesn't match with my experience at all. If you open up a math book and see integral signs everywhere, that immediately gives you hints for the kind of domain you're dealing with. If, on the other hand, you see mostly polynomial equations, then you're probably not worried about limiting processes. Mathematical symbols, at the graduate level and beyond, take on a communicative role in addition to the pure algebraic one you internalize during undergrad.
> In fact, you'll hardly find novel symbols [in any good mathematical book]
The average working mathematician has a working knowledge of at least a hundred squiggles. APL has much less. I don't quite see your point. It's not like APL programs are willy-nilly introducing new symbols.
> But that's good! It means there are less possible sources of truth, less things to update when something changes, and less context switching.
What would you rather read? 30-ish equations or PyTorch library code? Which do you think would be easier to grok? I am, of course, referring to the 30-line self-contained APL implementation of a neural net with performance on par with PyTorch:
Hsu and Serrão, U-net CNN in APL: https://www.dyalog.com/uploads/conference/dyalog22/presentat...
To be clear, I am not making an arguing for APL; I am sharing my direct experience. Despite the completely natural intuition to the opposite, APL expressions turn out be experienced as readable. More than that, though, APL programs are able to make overall architecture and design readable in a way that's unseen in supposedly "readable" languages.
While you come up with arguments for why APL is unreadable, I'll continue to write readable APL :P Why not join me instead!
From Alan Perlis in APL's early days: "The large number of primitive functions, at first mind-numbing in their capabilities, quickly turn out to be easily mastered, soon almost all are used naturally in every program — the primitive functions form a harmonious and useful set."
