> Terseness in the programming language helps at the microscopic level. And even more at the sub-system level. In practice I've found I can efficiently unders

> Terseness in the programming language helps at the microscopic level. And even more at the sub-system level. In practice I've found I can efficiently understand and work with chunks of code that I can immediately see + a dozen or so helper functions + 4-5 in-context/highly contextual other functions. Everything else exists only at a very high level. In c# I can see around 4-5 functions on my dual screens. In APL it is closer to 100 functions. > A pipeline of 13 operations is hard to understand, whether their names are one-character glyphs or 4-8 I don't think this is true and thankfully significantly fewer developers believe this is true than they did 10 years ago thanks to linq/streams. By day I'm a c# dev and most of my colleagues can easily understand a long linq chain. The mental complexity in linq almost always comes from heavily nested linq rather than from the number of operations. > This is the problem with APL programs and programmers: failure to decompose complex operations into small functions with clear names. The clarity of a name comes from the context, density, domain, and usage. For example a single letter variable in a 5 line loop is often crystal clear. So is a 2 letter variable used consistently hundreds of times throughout a code base. So is a single word only used once that comes from the business domain. I've found APL allows you to get rid of many pointless intermediate names and in doing so it increases the clarity of the code. In a language like c# this can cause significant and problematic code duplication - in practice in APL it's not a big issue.