Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard.
I hear it's gaining traction, though, so it's likely many of the problems you mention will be fixed or mitigated, eventually.
Also note that other languages often support non-ASCII identifiers as well --- for example, `σ` is a completely valid identifier name in Python (though it is more restrictive than Julia, `σ²` is not valid in Python and yet is valid in Julia). It even works in C, but that might just be a GNU extension.
Also in physics, sometimes you get really large expressions with a lot of Greek letters and operators. In the paper, you make it a double-wide multiline equation with LaTeX. It makes a big difference if that corresponds to a few lines of Greek symbols in your code, and not twenty.
I do. It's a simple \cbrt<tab> away in any editor worth their salt, and it greatly improves readability of computation-heavy code – ∛(ϵ² + ξ³) ≤ Φ(π) is much clearer than the ASCII equivalent.
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.
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.
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.
I also am not really a fan in many cases, but in the case of Bayesian models it makes so much more sense to write "σ" than "sigma". In the case of these complex models, being able to stay closer to the math reduces complexity for the reader. Also, you don't have to use Unicode in your own Julia codebase. It's more of an extra feature which you can use if you want.