3 ms·

> Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard. There's a curious

> Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard. There's a curious blindspot among coders with regard to customizing their main interface with their machines. Keyboards are heavily customizable. Some wins are extremely easy: If you want instant access to all Greek letters on a Mac (e.g.), you can have your caps lock key toggle between your standard layout and the Greek layout. (no \alpha, just α.) The rabbit hole runs deep from there if you are adventurous. Look at all the option key symbols you don't use. Swap them out for nice things like real arrows, ∈, and whatever you fancy. Maybe you have restraints or biases about work code being all ASCII, but typeability is up to you.

qsort 5y ago
Customization is a double edged sword though. A keyboard is simple and universal, and it's always the same, my skills transfer between machines, operating systems, languages, software, etc. Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. > Maybe you have restraints or biases about work code being all ASCII I'm heavily biased towards all-ASCII for everything except explicitly multilingual contexts (UIs, display formats, browsers, document editing, etc.). As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. A few reasons why: - It's basically guaranteed something somewhere will screw up the encoding. ASCII is the safest subset. - Better ability to quickly, reliably input characters across machines and tech stacks. - Easy to memorize. Characters are easily and immediately recognizable by everyone worldwide. - Some fonts might lack support for some non-ASCII characters. - Many non-ASCII characters are just plain unreadable. On my screen, lowercase alpha looks like a lowercase latin "A". I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble.
- hyperjeff 5y ago
  > Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. As a data point of one, I've found the return to be enormous and the investment suprisingly small. You have a whole lifetime of typing ahead, so what's a small investment of time compared to that? Just something to consider. > As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. People can vote by using the languages and tools they want, but I have been waiting for that limitation to die for quite some time. I also use function names longer than 6 characters. That said, I realize I'm lucky enough to be in charge of my own programming environments and don't have to worry about its adoption in unknown limited scenarios. > I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble. Again, just as a data point, I've never found this to be an issue (if one is prudent and not obnoxious with it), though the language support needs to be in place. In my main language these days, Swift, it's fine. Julia and Kotlin too.
leephillips 5y ago
Absolutely. On Linux it’s as simple as defining a “dead Greek” key, and you have access to the whole Greek alphabet. When I hear people complaining about the terrible burden that Julia allows Greek letters, to me it sounds like someone complaining that it allows uppercase letters. Same thing: one modifier key.

qsort 5y ago

Customization is a double edged sword though. A keyboard is simple and universal, and it's always the same, my skills transfer between machines, operating systems, languages, software, etc. Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. > Maybe you have restraints or biases about work code being all ASCII I'm heavily biased towards all-ASCII for everything except explicitly multilingual contexts (UIs, display formats, browsers, document editing, etc.). As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. A few reasons why: - It's basically guaranteed something somewhere will screw up the encoding. ASCII is the safest subset. - Better ability to quickly, reliably input characters across machines and tech stacks. - Easy to memorize. Characters are easily and immediately recognizable by everyone worldwide. - Some fonts might lack support for some non-ASCII characters. - Many non-ASCII characters are just plain unreadable. On my screen, lowercase alpha looks like a lowercase latin "A". I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble.

hyperjeff 5y ago
> Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. As a data point of one, I've found the return to be enormous and the investment suprisingly small. You have a whole lifetime of typing ahead, so what's a small investment of time compared to that? Just something to consider. > As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. People can vote by using the languages and tools they want, but I have been waiting for that limitation to die for quite some time. I also use function names longer than 6 characters. That said, I realize I'm lucky enough to be in charge of my own programming environments and don't have to worry about its adoption in unknown limited scenarios. > I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble. Again, just as a data point, I've never found this to be an issue (if one is prudent and not obnoxious with it), though the language support needs to be in place. In my main language these days, Swift, it's fine. Julia and Kotlin too.

leephillips 5y ago

Absolutely. On Linux it’s as simple as defining a “dead Greek” key, and you have access to the whole Greek alphabet. When I hear people complaining about the terrible burden that Julia allows Greek letters, to me it sounds like someone complaining that it allows uppercase letters. Same thing: one modifier key.