"a^2 + b^2 = c^2" is usually preferred over "The sum of the squares of the orthogonal sides of a right triangle is commensurate with the square of the hypotenuse,"
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".
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.
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.
Symbols are mostly useful for symbolic manipulation
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:
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!
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.
The title of the book also does that. Few books, papers, articles or exercises consist exclusively of symbols. I just took some random math papers from Arxiv and most of them are extremely wordy, and most of the symbols used are letters are names for values and functions defined right there, not operators that you need to reference elsewhere for the definition.
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:
I mean, obviously the PyTorch library code. Not even talking about symbols and syntax, at least the PyTorch code has readable names. We could also mention the lack of spacing to match different concepts or groups of operations.
I find it really funny that the claim is "APL is like math" when precisely APL does things that are very much frowned upon in math: excessive use of symbols, long symbolic equations, lack of literal explanations...
I mean, obviously the PyTorch library code. Not even talking about symbols and syntax, at least the PyTorch code has readable names.
Do you realize that there are vastly more "readable names" in the PyTorch library than there are bytes in the APL implementation of that neural net? I am fairly confident you could learn APL and grok the code in that paper faster than you could grok the PyTorch library code.
I feel like you're getting hung up on a few unfamiliar squiggles. They're really not that big of a deal, and the reality is that APL code in the wild has comments, READMEs, and all that jazz to provide helpful context. Then the APL code gets out of your way so you can focus on the big picture.
It might be hard to believe, but again, no matter how many reasonable arguments you may have against APL's readability, I'm simply sharing that real experience with the language shows otherwise. This is coming from someone who's only been futzing around with APL for about a year or so, to boot.
I find it really funny that...
I like your strong skepticism. You'd probably be pretty good at APL if you ever developed the interest.
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."
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.
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.
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.
I have counted at least 30 symbols that I haven’t seen in an undergraduate degree + master degree, not counting symbols that I know but haven’t seen used directly as symbols (eg , or ?) but as punctuation. Of course I might have forgotten some of them but I think it’s undeniable that APL introduces a lot of new symbols.
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
Not the arguments themselves but the amount of arguments. Operator overloading is also context dependency. Maybe we’re getting lost in the words: what I mean is that you can’t say for sure what a certain symbol means unless you have the symbols around it. For example, in C / always means “divide what’s on the left by what’s on the left”, but * is context dependent because it can either be multiplication or pointer dereference.
That is, maybe symbols encourage this design choice, but in themselves they aren't the problem.
If some part of a language encourages things that we consider bad decisions, then that part is a problem. Again returning to C, one could say that the memory allocation system isn’t a problem despite the fact that it makes it really easy to cause leaks and bad memory accesses.
A language with 74 symbols, many of which are related, is what makes it possible to teach APL quickly
Quickly… compared to what? Because I honestly don’t think an average person is going to learn APL faster than any mainstream language.
APL was near-mainstream in the 1980s, and I think there are better explanations for its decline since.
It’s not just that APL has declined but in general the array programming paradigm that it pioneered hasn’t really taken off. For example, LISP declined quite a lot but new similar, functional languages have appeared and attracted interest.
J uses ASCII. Built-in symbols use dot (.) and colon (:) as part of a symbol. In J vocabulary, https://www.jsoftware.com/help/dictionary/vocabul.htm , I counted less than 150 built-in symbols. Even if you double it as monadic/dyadic variations, that's less than 300. I definitely don't know many of them, and still able to write some programs, like a parser generator; I think those symbols are closer to a standard library - i.e. with C we need to get familiar with printf, getc or strcpy. As with mathematics in elementary school, you start with few simpler ones, then gradually add some more useful ones, then the rest is optional for cases when you want or need them.
In practice a lot of J symbols are either already known or rather obvious.
It's like a standard library except it's harder to search for the symbol you want via autocomplete, harder to infer the meaning of symbols you don't know (even when the C standard library has some terrible names) and easier to confuse (from the page, having symbols like ,. and .. or ,: and .:).
Of course, I assume that people end up knowing most of them and that not all of them are necessary. I'm not arguing that, I'm saying that symbols are an extra cognitive load and I find it funny that the argument for them is "well this is how is done in math" when precisely there's a push in math to avoid using excessive symbols.
Quickly… compared to what? Because I honestly don’t think an average person is going to learn APL faster than any mainstream language.
It's known that non-professional programmers often preferred APL to other languages, it was easier to express their problems in APL than in something else.
A possible point of confusion: "I count at least 50 math symbols" wasn't in reference to APL, just my count of how many symbols are widely used in mathematics. Contrasting your claim that APL has "far more symbols than I've ever seen in my math degree". Agreed, most of APL's symbols are not found in mathematics.
I refer you again to Perlis, same paragraph: "It is true that BASIC and FORTRAN are easier to learn than APL, for example, a week versus a month. However, once mastered, APL fits the above requirements much better than either BASIC or FORTRAN or their successors ALGOL 60, PL/I and Pascal."
For example, in C / always means “divide what’s on the left by what’s on the left”, but * is context dependent because it can either be multiplication or pointer dereference.
No, it could mean a start of a comment. Multi-line or single-line - depends on context. Similarly, there are multi-character operators - both in C and J. And while some idioms in APL could be seen as "atomic" (like (+/ % #) in J), they are actually a function composition, so they'd better be seen and understood in context, which is rather small.
My point was that mathematical symbols are also context dependent and yet they work and are useful, so I don't get your argument of context dependency against APL's symbols.
What rules? I am only saying that symbols add cognitive load, even more if they're context dependent. I don't think that's controversial at all, and APL and other array languages do have context-dependent symbols.
And yes, I tried learning an array language but I didn't get far for two reasons: one, I didn't really see where could I apply it; two, it's really hard to discover things and learn incrementally when you can't really use autocomplete or even Google (punctuation and symbols are not well supported in search engines) to help with the large set of symbols/operations with multiple meanings each.
Comments
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".
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.
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.
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.
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.
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!
The title of the book also does that. Few books, papers, articles or exercises consist exclusively of symbols. I just took some random math papers from Arxiv and most of them are extremely wordy, and most of the symbols used are letters are names for values and functions defined right there, not operators that you need to reference elsewhere for the definition.
I mean, obviously the PyTorch library code. Not even talking about symbols and syntax, at least the PyTorch code has readable names. We could also mention the lack of spacing to match different concepts or groups of operations.
I find it really funny that the claim is "APL is like math" when precisely APL does things that are very much frowned upon in math: excessive use of symbols, long symbolic equations, lack of literal explanations...
Do you realize that there are vastly more "readable names" in the PyTorch library than there are bytes in the APL implementation of that neural net? I am fairly confident you could learn APL and grok the code in that paper faster than you could grok the PyTorch library code.
I feel like you're getting hung up on a few unfamiliar squiggles. They're really not that big of a deal, and the reality is that APL code in the wild has comments, READMEs, and all that jazz to provide helpful context. Then the APL code gets out of your way so you can focus on the big picture.
It might be hard to believe, but again, no matter how many reasonable arguments you may have against APL's readability, I'm simply sharing that real experience with the language shows otherwise. This is coming from someone who's only been futzing around with APL for about a year or so, to boot.
I like your strong skepticism. You'd probably be pretty good at APL if you ever developed the interest.
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
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.
Yes, but APL itself introduces a ton of new symbols. In fact, far more symbols than I've ever seen in my math degree.
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.
Is that so? Compare all Dyalog primitives to some math ones:
- https://aplwiki.com/wiki/Dyalog_APL#Primitives
- 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.
I have counted at least 30 symbols that I haven’t seen in an undergraduate degree + master degree, not counting symbols that I know but haven’t seen used directly as symbols (eg , or ?) but as punctuation. Of course I might have forgotten some of them but I think it’s undeniable that APL introduces a lot of new symbols.
Not the arguments themselves but the amount of arguments. Operator overloading is also context dependency. Maybe we’re getting lost in the words: what I mean is that you can’t say for sure what a certain symbol means unless you have the symbols around it. For example, in C / always means “divide what’s on the left by what’s on the left”, but * is context dependent because it can either be multiplication or pointer dereference.
If some part of a language encourages things that we consider bad decisions, then that part is a problem. Again returning to C, one could say that the memory allocation system isn’t a problem despite the fact that it makes it really easy to cause leaks and bad memory accesses.
Quickly… compared to what? Because I honestly don’t think an average person is going to learn APL faster than any mainstream language.
It’s not just that APL has declined but in general the array programming paradigm that it pioneered hasn’t really taken off. For example, LISP declined quite a lot but new similar, functional languages have appeared and attracted interest.
J uses ASCII. Built-in symbols use dot (.) and colon (:) as part of a symbol. In J vocabulary, https://www.jsoftware.com/help/dictionary/vocabul.htm , I counted less than 150 built-in symbols. Even if you double it as monadic/dyadic variations, that's less than 300. I definitely don't know many of them, and still able to write some programs, like a parser generator; I think those symbols are closer to a standard library - i.e. with C we need to get familiar with printf, getc or strcpy. As with mathematics in elementary school, you start with few simpler ones, then gradually add some more useful ones, then the rest is optional for cases when you want or need them.
In practice a lot of J symbols are either already known or rather obvious.
It's like a standard library except it's harder to search for the symbol you want via autocomplete, harder to infer the meaning of symbols you don't know (even when the C standard library has some terrible names) and easier to confuse (from the page, having symbols like ,. and .. or ,: and .:).
Of course, I assume that people end up knowing most of them and that not all of them are necessary. I'm not arguing that, I'm saying that symbols are an extra cognitive load and I find it funny that the argument for them is "well this is how is done in math" when precisely there's a push in math to avoid using excessive symbols.
It's known that non-professional programmers often preferred APL to other languages, it was easier to express their problems in APL than in something else.
A possible point of confusion: "I count at least 50 math symbols" wasn't in reference to APL, just my count of how many symbols are widely used in mathematics. Contrasting your claim that APL has "far more symbols than I've ever seen in my math degree". Agreed, most of APL's symbols are not found in mathematics.
I refer you again to Perlis, same paragraph: "It is true that BASIC and FORTRAN are easier to learn than APL, for example, a week versus a month. However, once mastered, APL fits the above requirements much better than either BASIC or FORTRAN or their successors ALGOL 60, PL/I and Pascal."
No, it could mean a start of a comment. Multi-line or single-line - depends on context. Similarly, there are multi-character operators - both in C and J. And while some idioms in APL could be seen as "atomic" (like (+/ % #) in J), they are actually a function composition, so they'd better be seen and understood in context, which is rather small.
And +5 is not the same as 2+5. One is a sign and the other addition...
Yes, so therefore + is context dependent. Some context dependency is unavoidable, but having everything be context dependent is bad design IMHO.
My point was that mathematical symbols are also context dependent and yet they work and are useful, so I don't get your argument of context dependency against APL's symbols.
You're really making up and bending rules here. Did you learn an array language to see things both ways?
What rules? I am only saying that symbols add cognitive load, even more if they're context dependent. I don't think that's controversial at all, and APL and other array languages do have context-dependent symbols.
And yes, I tried learning an array language but I didn't get far for two reasons: one, I didn't really see where could I apply it; two, it's really hard to discover things and learn incrementally when you can't really use autocomplete or even Google (punctuation and symbols are not well supported in search engines) to help with the large set of symbols/operations with multiple meanings each.