A terse notation is useful for grokking code, as the information is spread across less characters that need to be interpreted by the brain.
If you expanded all names, that would add cognitive overhead for all users and reduce the useful information per character, and potentially reduce the information that can fit on a screen significantly.
While I'll agree that "cryptic sequences" are a more steep learning slope, they allow for much faster understanding of larger blocks of data/assembly once the "cryptic sequences" themselves are understood.
Terse doesn’t necessarily mean opaque. Even if sticking to three letter words was an absolute requirement, there are plenty of English words that would make a better jobs at conducting the idea without falling into a collection of unpronounceable idiosyncratic terms.
> as the information is spread across less characters that need to be interpreted by the brain.
That’s not how the brain interpret text generally, once reading is fully acquired. Words, or even group of words are taken all together.
Would it be for scriptural compactness alone, it would be far more efficient to use dedicated symbols optimized for that purpose. But if the idea is to optimize readability for an unknown large audience, then this is most likely a rather misguided choice.
>If you expanded all names, that would add cognitive overhead for all users
Well, I disagree. To my mind it would on the contrary significantly reduce cognitive load for those not already familiar with the uselessly abstruse terms, and add nothing to those already accustomed to code constructions in the machine specific language.
>reduce the useful information per character
Once again, this is a very poor metric for human interpretation of textual works.
> potentially reduce the information that can fit on a screen significantly.
So what? Number of signs displayed on the screen is certainly not the limiting factor here. How much juxtaposed signs a human attention can meaningfully handle is far more compelling.
>they allow for much faster understanding of larger blocks of data/assembly once the "cryptic sequences" themselves are understood.
I am not aware of any study that supports such a statement on empirical evidences. Maybe you can point me to such a study and help me change my mind?
Assembly, back in the time of punched cards, had some reasonable rationals for avoiding input sequences longer than strictly necessary. Bu these rational no longer fit the contemporary digital landscape.
I am not disagreeing with you, but the width of “tokens” we parse does matter — it’s much harder to spot a typo in a long word than in a short one, and one tends to read assembly by pattern matching on the instruction word, so I believe better, but still relatively short names would be the optimum.
(E.g. jump_if_greater would not be that good, jge is too short and unless you actually know what it is, it is hard to decipher, jmp_ge is not a bad compromise)
If you expanded all names, that would add cognitive overhead for all users and reduce the useful information per character, and potentially reduce the information that can fit on a screen significantly.
While I'll agree that "cryptic sequences" are a more steep learning slope, they allow for much faster understanding of larger blocks of data/assembly once the "cryptic sequences" themselves are understood.