While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…
on Windows you can simply type `Windows key` + `.` and easily find it there, tho if languages use such characters they really should also have alternatives
Because people in non-English-speaking countries are perfectly within their rights to name source code entities in their native language instead of either having to mangle words into ASCII representations (possibly even leading to ambiguities in case of near-homonyms that have identical ASCII bastardizations!) or being forced to awkwardly translate domain terminology into English which is a task that may be any of th…
Sure, everybody has 'rights' but if I were to come across a workplace in my country where programmers were using much of our native language in the code I would consider it a red flag and I would expect to find amateurish practices in other places as well. The thing is that English is the lingua franca of programming and that ASCII is the lingua franca of source files. The highest quality manual that you are going to…
I'm an english native speaker, so on the one hand, I'm glad english is so common in programing. On the other, I can't help but wonder, aren't other languages actually better for the job at hand? Chinese, Japanese kanji, or to a lesser extent, Hangul, all have this kind of awesome mix of concision and expressiveness. I'm not really a language guy, but I've been tempted to learn chinese just for this reason. It also has a really cool feature of being much easier to read than to write - which makes a certain level of 'reader-first' coding practice built into the language itself. You could cut down on the number of sigils, line noise, even play around with different ways to organize source code (there are, for instance, palindrome poems written in chinese that use two dimensions, which would be basically impossible in english).
Because people in non-English-speaking countries are perfectly within their rights to name source code entities in their native language instead of either having to mangle words into ASCII representations (possibly even leading to ambiguities in case of near-homonyms that have identical ASCII bastardizations!) or being forced to awkwardly translate domain terminology into English which is a task that may be any of th…
Sure, everybody has 'rights' but if I were to come across a workplace in my country where programmers were using much of our native language in the code I would consider it a red flag and I would expect to find amateurish practices in other places as well. The thing is that English is the lingua franca of programming and that ASCII is the lingua franca of source files. The highest quality manual that you are going to…
For me it seems bad to design some systems in English like public administrations software or following a law very closely (there are even no translated concepts in things like taxation and legal system) and data exchange formats should be in the language it matters (for example, all electronic bills in Spain are XML with entities in Spanish), so if you want a 1:1 mapping you need to use native language.
While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…
Maybe it’s time for a plugin that does this (or maybe it already exists?): You press the backslash key, enter the name of the symbol, then press enter, and the symbol will show up in your buffer. Something like: \lambda -> λ \Lambda -> Λ \\ -> \ et cetra.
Emacs has this plugin (well not a plugin because it’s built in). One can select an input mode. Some translate directly (e.g. a Greek input mode where typing a gives an alpha). There is also a TeX mode like what you describe and another mode which is more concise (e.g. &a for alpha, where the means Greek). The difference from what you described is that instead of some escape sequence for these special prefixes, they are just never converted if they don’t match and you move the point away.
Maybe it’s time for a plugin that does this (or maybe it already exists?): You press the backslash key, enter the name of the symbol, then press enter, and the symbol will show up in your buffer. Something like: \lambda -> λ \Lambda -> Λ \\ -> \ et cetra.
A dedicated global compose key solves this problem very elegantly. Hitting the ◆ compose key (right alt for me) followed by a series of intuitive characters inserts the corresponding character. For example: ◆ - - - produces an em dash (—) ◆ - - . produces an en dash (–) ◆ ' e produces é ◆ | c produces the cent symbol (¢) Usually, you can just guess the combination and be right 3/4 times. Otherwise, it's fairly easy t…
macOS has something very similar with the option key, but the set of characters doesn’t include all Greek letters which is incredibly annoying: https://sites.psu.edu/symbolcodes/mac/codemac/
While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…
Agda[0] and Coq and other languages for formalising mathematics (they are also programming languages) make a lot of use of Unicode to make the mathematical statements readable. Here is an example: > ∑-+-distribute : ∑ (A + B) C ≃ (∑ A (C ∘ left)) + (∑ B (C ∘ right)) This is quite readable and would be understandable to someone who did not know Agda or the library in particular, but who understood the subject material…
> The Plan9 operating system invented the compose key, which makes writing unicode characters easy enough for anyone to use them. Unfortunately, it requires a bit of setup to make the compose key work in X on Linux or *BSD
While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…
on Windows you can simply type `Windows key` + `.` and easily find it there, tho if languages use such characters they really should also have alternatives
that only opens the emoji picker, not a generic unicode picker.
While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…
> Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice I can imagine a simple remedy for this. Have the IDE suggest symbol replacements whenever the use types the name of the symbol. 'lambda' causes λ to be suggested.
That is, if they know that “λ” is “lambda”, which honestly might not extend to many of the Greek letters, to say nothing of Unicode.
looking forward to the first homograph attack in rust
Hmm. What would you attack? That is, if you were writing a crate that I was thinking of using in my program, how would homographs allow you to compromise my code?
Here’s a somewhat contrived “attack”: I write a crate with two functions that are named similarly, wait for you to integrate it, then file a pull request using the Unicode function name (and hence calling the malicious function) and be relatively assured that if you looked up the function you’d stop reading code at the ASCII one.
While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…
Because people in non-English-speaking countries are perfectly within their rights to name source code entities in their native language instead of either having to mangle words into ASCII representations (possibly even leading to ambiguities in case of near-homonyms that have identical ASCII bastardizations!) or being forced to awkwardly translate domain terminology into English which is a task that may be any of th…
As a non-native-English-speaker, the idea of having invisible bugs in code due to lookalike characters terrifies me.
The allowed set of characters would have to be vetted very carefully before I'd consider non-ASCII.
