undefined | Better HN

0 pointsxelxebar3y ago0 comments

> 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/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!

0 comments

2 comments · 1 top-level

gjulianm3y ago· 1 in thread

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

xelxebarOP3y ago

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

j / k navigate · click thread line to collapse