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.
Comments
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.