8 ms·
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 symb
by 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 agoAPL 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 agoIs 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> 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.
- xelxebar 4y ago> 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: Hsu and Serrão, U-net CNN in APL: https://www.dyalog.com/uploads/conference/dyalog22/presentations/D08_ICFP_Submission.pdf 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!
- gjulianm 4y ago> 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...