6 ms·

Hehe. You are absolutely right. I was hoping someone would point that out because it highlights another strong point of APL, in my opinion. APL expressions, ju

Hehe. You are absolutely right. I was hoping someone would point that out because it highlights another strong point of APL, in my opinion. 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.

gjulianm 4y ago
I am not a practicing mathematician but I have my degree in math, and from that point of view I do not agree at all with you. Symbols are mostly useful for symbolic manipulation, but any good mathematical book will try to keep the number of new symbols introduced at a minimum precisely because they add a lot of cognitive overhead. In fact, you'll hardly find novel symbols, mostly there are shortened function names (e.g., Hom(G) for the set of homomorphisms over a group). Considering how code is read more than written, adding context-dependent symbols that add cognitive overhead isn't really an advantage. > 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.
- mlochbaum 4y ago
  APL designers also work to keep symbols to a minimum, and any given APL program introduces zero new symbols. They're not context-dependent (why did you think this?), and very few are domain-specific. Various languages differ a bit on this: J has more primitives, and several for number theory or other specific branches of math, while K has very few, and all are general. 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." https://www.jsoftware.com/papers/perlis77.htm https://www.jsoftware.com/papers/perlis77.htm
  - gjulianm 4y ago
    > They're not context-dependent (why did you think this?), They are, ρ5 is not the same as 2ρ5. A lot of symbols mean different things depending on whether they're being applied as monadic or dyadic operators. The circle operator is specially fun: A○B will apply a certain trigonometric operation depending to B depending on the value of A. That, to me, is very context-dependent. > and any given APL program introduces zero new symbols. Yes, but APL itself introduces a ton of new symbols. In fact, far more symbols than I've ever seen in my math degree. > 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." This is a tautology to me, "once you master things you use them naturally". Of course. But the fact that APL and similar languages are very obscure would point to "once you master things" not being that easy and natural.
    - mlochbaum 4y ago
      Is that so? Compare all Dyalog primitives to some math ones: - https://aplwiki.com/wiki/Dyalog_APL#Primitives https://aplwiki.com/wiki/Dyalog_APL#Primitives - https://en.wikipedia.org/wiki/List_of_mathematical_symbols_by_subject https://en.wikipedia.org/wiki/List_of_mathematical_symbols_b... APL shows 74 symbols. I count at least 50 math symbols that seem very likely to show up in an undergraduate degree; notably, 26 symbols +-×÷|⌊⌈!~∧∨⍲⍱<≤=≥>≠∊∩∪≡≢∘ in APL are taken from math with similar meanings. The arguments to a primitive are not context! You may as well call addition context-dependent because 1+n increments n while 2+n increments it twice. You're describing overloading, and I do really dislike the way ○ handles things (in BQN trig just goes in the •math namespace). However, I don't think it's right to put the blame on symbols, as a trig(code, argument) function could be defined to do the same thing. That is, maybe symbols encourage this design choice, but in themselves they aren't the problem. Note "quickly" and "easily" in Perlis's quote. A language with 500 symbols would seem to me to match your description before, and I would find it hard to believe it would be quickly or easily mastered. A language with 74 symbols, many of which are related, is what makes it possible to teach APL quickly: Perlis's month would be a few a day. APL was near-mainstream in the 1980s, and I think there are better explanations for its decline since.

gjulianm 4y ago

I am not a practicing mathematician but I have my degree in math, and from that point of view I do not agree at all with you. Symbols are mostly useful for symbolic manipulation, but any good mathematical book will try to keep the number of new symbols introduced at a minimum precisely because they add a lot of cognitive overhead. In fact, you'll hardly find novel symbols, mostly there are shortened function names (e.g., Hom(G) for the set of homomorphisms over a group). Considering how code is read more than written, adding context-dependent symbols that add cognitive overhead isn't really an advantage. > 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.

mlochbaum 4y ago
APL designers also work to keep symbols to a minimum, and any given APL program introduces zero new symbols. They're not context-dependent (why did you think this?), and very few are domain-specific. Various languages differ a bit on this: J has more primitives, and several for number theory or other specific branches of math, while K has very few, and all are general. 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." https://www.jsoftware.com/papers/perlis77.htm https://www.jsoftware.com/papers/perlis77.htm
- gjulianm 4y ago
  > They're not context-dependent (why did you think this?), They are, ρ5 is not the same as 2ρ5. A lot of symbols mean different things depending on whether they're being applied as monadic or dyadic operators. The circle operator is specially fun: A○B will apply a certain trigonometric operation depending to B depending on the value of A. That, to me, is very context-dependent. > and any given APL program introduces zero new symbols. Yes, but APL itself introduces a ton of new symbols. In fact, far more symbols than I've ever seen in my math degree. > 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." This is a tautology to me, "once you master things you use them naturally". Of course. But the fact that APL and similar languages are very obscure would point to "once you master things" not being that easy and natural.
  - mlochbaum 4y ago
    Is that so? Compare all Dyalog primitives to some math ones: - https://aplwiki.com/wiki/Dyalog_APL#Primitives https://aplwiki.com/wiki/Dyalog_APL#Primitives - https://en.wikipedia.org/wiki/List_of_mathematical_symbols_by_subject https://en.wikipedia.org/wiki/List_of_mathematical_symbols_b... APL shows 74 symbols. I count at least 50 math symbols that seem very likely to show up in an undergraduate degree; notably, 26 symbols +-×÷|⌊⌈!~∧∨⍲⍱<≤=≥>≠∊∩∪≡≢∘ in APL are taken from math with similar meanings. The arguments to a primitive are not context! You may as well call addition context-dependent because 1+n increments n while 2+n increments it twice. You're describing overloading, and I do really dislike the way ○ handles things (in BQN trig just goes in the •math namespace). However, I don't think it's right to put the blame on symbols, as a trig(code, argument) function could be defined to do the same thing. That is, maybe symbols encourage this design choice, but in themselves they aren't the problem. Note "quickly" and "easily" in Perlis's quote. A language with 500 symbols would seem to me to match your description before, and I would find it hard to believe it would be quickly or easily mastered. A language with 74 symbols, many of which are related, is what makes it possible to teach APL quickly: Perlis's month would be a few a day. APL was near-mainstream in the 1980s, and I think there are better explanations for its decline since.