A physicist at IBM named John Slonczewski recently passed away, and my father-in-law, also a physicist, going through his papers containing what appears to be APL code. He believes he can derive formulas from the code but I think that without knowledge of the underlying Dfns, it is not useful. Sharing with the group for fun. The APL is not complex. i.imgur.com/Bxsg3IO.jpg

@Adám I-beam cheatsheet.

@Jeremygee I was wondering a few days back, that APL would be the best code to write on paper (my uni java exams would've been so good if they could be written in APL) (writing java on paper is so bad :)) ).

@sloorush Aaron Hsu does this extensively, I hear. With a fountain pen, no less!

Definitely worth playing with. In the bit that I've done, it's been quite a natural experience. Takes getting used to writing some of the symbols, though.

Interesting. Modified multiple assignment performs f on each of the names individually. I got tripped up, thinking (a b c)f←⊂x y z would be the same as a b c←(a b c)f⊂x y z. Instead it's a←a f⊂x y z ⋄ b←b f⊂x y z ⋄ c←c f⊂x y z`.

@B.Wilson ooh

@B.Wilson While indeed the implicit ¨ is odd, imo at least, your stated equivalence isn't quite correct. It is a b c←(a b c)f¨⊂x y z or a←a f x y z ⋄ b←b f x y z ⋄ c←c f x y z. I believe the reason for an implicit each actually has nothing to do with the multiple-ness, but rather the not-just-simple-ness of the assignment, such that there's an implicit each in a[3 1 4 1]+←1. If not for that, a[1] wouldn't get incremented twice.

I also write APL by hand on occasion, and I've seen a few others do too.

@B.Wilson Thanks, I'll have that fixed. (The default is 0.)

(Logged as issue 20325)

@Adám Ah, you're right (as usual)! Added an extraneous Enclose.

Hrm. Nice example with a[3 1 4 1]. So the implict Each is a property of all forms of modified assignment?

Yes, I believe so. If you don't want it, you can use @ instead.

mmm, the link to the query didn't work. The query is: ⎕RL

@sloorush Thanks. Fixed.

@Adám Thank you

@B.Wilson Fixed. (Change'll show up when we next build and release the docs set.)

@Adám@B.Wilson renaming the file to SQAPL.dws worked. Adám I think it's correct to say this is a bug in loaddata.dws- as distributed it's not cross-platform compatible

@RoundTower Logged as issue 20335 and will be fixed now (for inclusion in future builds).

@sloorush oh gosh the amount of paper wasted for a java exam :)

This is an insight that I wouldn't have caught. I appreciate it.

@Jeremygee hahaha! I swear

Is there an APL font that does not look so dim on dark background?

APL2741, SImPL, and Courier are too thing for a dark color scheme.

Even APL385 cannot save this color scheme

*thin

that seems more like an issue with the color scheme and not the font

@LdBeth APL385 is quite bold, but how do you envision that a font can increase contrast?

For certain opentype fonts there is possibility to get extra bold variants, unfortunately APL385 has no such features.

Some systems are pretty good at artificially bolding fonts, but I still don't understand how that can help here.

I ended up switching to a much brighter color for operators and functions, since in APL code they are much common than identifiers. :)