4 ms·

If you think about it most languages have sacrificed a lot simply to give mathematical operators their "traditional" ASCII meanings. Had character assignments

If you think about it most languages have sacrificed a lot simply to give mathematical operators their "traditional" ASCII meanings. Had character assignments been based on frequency of need or just convenience, you'd surely have seen things like minus-signs in variable names more often. I would love to see a UTF-8 or other Unicode keyboard so that it's very fast to enter "real" symbols (partially programmable too). Why for instance does my numeric keypad need another "/" or an asterisk...it could now have "÷" and "×" instead. In the next few years, given more common Unicode support in keyboards and companion programs (text editors and terminals already do a decent job), it would be interesting to see a language evolve to require actual symbols for known operators. Then you really would have to type "6 × 5 ÷ 3", not the ASCII hack "6 * 5 / 3". It would also allow very interesting hyper-operators (as seen in old environments such as the Mac's MPW Shell, and now Perl 6). Wait...don't let Larry Wall see this or we'll have a "$≠" variable or something in Perl 7. ;)

ericrannaud 15y ago
Well, the problem is that I don't see how it would be possible to have a keyboard like this that would be really fast to type with. Even a visual keyboard, as on a tablet, that could arguably display any set of symbols, would still not really be a solution. You can only show less than 100 keys at a time, and you would have to switch layouts all the time, e.g. to get to that special 'alpha' or '!=' key. I find full UTF-8 support in identifiers a regrettable idea because these symbols are generally impossible to type quickly. This makes programming languages less universal. And I'm not even talking about symbols that look nearly identical but are actually different Unicode characters. The only solution that I would find acceptable, personally, is to display certain identifiers or ASCII strings as fancy symbols. 'alpha', 'beta', '!=', 'ab / c' would be displayed using symbols, but the raw text file would contain the ASCII name. When editing a symbol, the actual name would be typed in. Or a syntax similar to Tex would be acceptable: '\alpha', '\dot', '\frac{10}{100}'. The display can be fancy, but the source file shouldn't be, IMO.
- makecheck 15y ago
  If identifiers are displayed as symbols, that's really no different than having keyboard support; in both cases you're hoping you can hit (ideally) one key and have the keyboard do what you want. Keyboards already have modes like the Shift key, it's just a matter of kicking the programmability up a notch. And who knows, maybe keyboards grow slightly and gain a 2nd keypad (on the left) with some new "common" keys. 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?). I don't think keyboards will change much until some related tech becomes cheaper, too. Two key ones I think are cheap mini-displays per key (so the whole keyboard can display new glyphs if need be), and a companion touch-screen for drawing non-trivial glyphs that are needed only occasionally. Or maybe they just give up on the idea of physical keys entirely and attach large touch screens as "the whole keyboard" for a desktop machine.
  - ericrannaud 15y ago
    > 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.

ericrannaud 15y ago

Well, the problem is that I don't see how it would be possible to have a keyboard like this that would be really fast to type with. Even a visual keyboard, as on a tablet, that could arguably display any set of symbols, would still not really be a solution. You can only show less than 100 keys at a time, and you would have to switch layouts all the time, e.g. to get to that special 'alpha' or '!=' key. I find full UTF-8 support in identifiers a regrettable idea because these symbols are generally impossible to type quickly. This makes programming languages less universal. And I'm not even talking about symbols that look nearly identical but are actually different Unicode characters. The only solution that I would find acceptable, personally, is to display certain identifiers or ASCII strings as fancy symbols. 'alpha', 'beta', '!=', 'ab / c' would be displayed using symbols, but the raw text file would contain the ASCII name. When editing a symbol, the actual name would be typed in. Or a syntax similar to Tex would be acceptable: '\alpha', '\dot', '\frac{10}{100}'. The display can be fancy, but the source file shouldn't be, IMO.

makecheck 15y ago
If identifiers are displayed as symbols, that's really no different than having keyboard support; in both cases you're hoping you can hit (ideally) one key and have the keyboard do what you want. Keyboards already have modes like the Shift key, it's just a matter of kicking the programmability up a notch. And who knows, maybe keyboards grow slightly and gain a 2nd keypad (on the left) with some new "common" keys. 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?). I don't think keyboards will change much until some related tech becomes cheaper, too. Two key ones I think are cheap mini-displays per key (so the whole keyboard can display new glyphs if need be), and a companion touch-screen for drawing non-trivial glyphs that are needed only occasionally. Or maybe they just give up on the idea of physical keys entirely and attach large touch screens as "the whole keyboard" for a desktop machine.
- ericrannaud 15y ago
  > 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.