[shakow]

If we programmed in Chinese, one would need to know thousands of characters to write any decent-sized program; if we programmed in Japanese, one would need to master several alphabets, if we were to program in Hindi, the very shape of our characters would depend of the context...

All in all, the upper/lower case problem does not seem to be that much of a waste of man-years.

[thaumasiotes]

> If we programmed in Chinese, one would need to know thousands of characters to write any decent-sized program; if we programmed in Japanese, one would need to master several alphabets

Right, because that's the difficult part. Memorizing 100 alphabets is significantly easier than memorizing the relevant Chinese characters. The syllabaries are zero percent of the difficulty of learning to read Japanese.

[Arnavion]

>if we were to program in Hindi, the very shape of our characters would depend of the context...

Eh? What context-dependent-shape-changing are you referring to? Hindi has a very normal alphabet. There are vowels, consonants, and a bunch of special ligatures for some combinations of those that are technically optional and could be done without. Nothing changes according to "context".

[shakow]

> are technically optional and could be done without

My bad, I thought those were mandatory.

[Arnavion]

Even if they were mandatory, they're just ligatures. There's no context about them.

[shakow]

The very concept of a ligature is to alter the letter depending on its surrounding context.

[Arnavion]

Okay, guess we disagree about what "context" means.

You can't write adam, you have to write Adam. This is because the letters don't carry enough information; you need to know the context that names are capitalized, which is information that is extrinsic to the text itself.

Similarly, you can't render a unified Han glyph without knowing the context of which language the text is in. This information is again extrinsic to the text itself - it is metadata about the text.

In comparison, when you can't write Hindi ru as r and u as you usually would but instead you have to write the letter ru as its own glyph, there is no extrinsic information needed. The letters are right there, so all the information for knowing how to render the letters is right there. There is no context needed.

But yes, if you define context to include surrounding letters, then yes you need "context" to render Hindi letters. But since the original context of this was the difficulty of supporting this context for programming identifiers, I'd say that this kind of "adjacent codepoints context" would not be something special to worry about anyway, because text renderers today already have to deal with this kind of "adjacent codepoints context" for emojis, etc.

[oaiey]

Especially considering that English ASCII fits into 128 characters including punctuation ... I do not want to start thinking how Chinese or Japanese fits into that.

In reality the ask is maybe: let us use 25 characters english without uppercase? Which we have in Basic and dozens of old style programming language however typically upper case.

[Arnavion]

In a universe where Chinese or Japanese were the prominent languages for program identifiers, there wouldn't be a requirement to fit into 128 characters in the first place. The dominant charset would probably be GB2312 / Shift-JIS which are multi-byte.