> Note that UTF-8 is quickly becoming the new "raw text file". The encoding of each symbol is very well defined and supported by programs already. It is actuall

> Note that UTF-8 is quickly becoming the new "raw text file". The encoding of each symbol is very well defined and supported by programs already. It is actually better to have that exact definition than an ASCII word that may or may not be supported by all editors (and if it's not, as you said some symbols look similar; which one is intended?). Not at all. You see 'A' on your screen: is it uppercase Latin 'a' or is it uppercase Greek alpha? Good luck, these are two distinct Unicode characters (with different UTF-8 encoding, obviously), but most fonts will (rightly) represent them identically. How is your keyboard going to handle that? Your tablet keyboard? How do you know which symbol to type in when editing code? It's completely unmaintainable and unreadable. In the scheme I described, if the word 'alpha' is not supported by the editor, then it displays the string 'alpha'. That's of course not ambiguous. And a good editor, in my scheme, would not display 'Alpha' as 'A' if it's well thought of, it would just display 'Alpha', which is not ambiguous and clear. If the source is UTF-8, on the other hand, should the editor display U+03B1 to avoid the visual ambiguity of 'A'? Can you remember what Greek (or otherwise) letter that is? Finally, note that there are 12 Unicode characters for the Greek letter alpha... See http://en.wikipedia.org/wiki/Alpha#Computer_encoding http://en.wikipedia.org/wiki/Alpha#Computer_encoding So it's completely misguided to accept arbitrary Unicode characters in identifiers. Because the only way to display such an identifier in an non-ambiguous way is to display the binary encoding... So, arguably, one could use a set of characters larger than ASCII for programming. But the full Unicode range is not it, there is way too much crap in there.