See also Perligata. Not saying Welsh isn't better. I'm neither a Perl nor Latin expert, so I just trust em when they say
> Latin is a surprisingly good fit for Perl. The rich case structure provides an abundance of plausible mappings for Perl data types and subroutine calls...
I'm not sure if I agree with it, but you could make an argument that programming languages are colored by the L1 languages of their initial designers. So you might see a bit of Japanese in Ruby, and a bit of Brazilian Portuguese in Lua. But programmers in general tend to have excellent English and are inspired overwhelmingly by languages written by English speakers, so it's difficult to evaluate.
I guess Ruby's compatibility errors for incompatible encodings comes from familiarity with Japanese encodings which presents problems most American programmers would be unfamiliar with.
I love this kind of stuff! It's important for source code to be able to handle non-ASCII characters but we need to be mindful of the different ways that an editor will "lie" to you about your code. The most recent example of this in Rust [1].
> As part of their research, Nicholas Boucher and Ross Anderson also uncovered a similar security issue identified as CVE-2021-42694 involving homoglyphs inside identifiers. Rust already includes mitigations for that attack since Rust 1.53.0. Rust 1.0.0 through Rust 1.52.1 is not affected due to the lack of support for non-ASCII identifiers in those releases.
The easy reaction is "Why are we allowing non-ASCII characters at all? Just so we can put emojis in our variable names?"
This project is a good example of why we do it. But as with everything, we need to be careful about it.
On a related note, I've always wondered: when code is written with Chinese ideographs in identifiers (variable names etc), is it typically more compact/narrow? I always struggle with variable naming because of the tradeoff between descriptiveness and length; do ideographs help?
The irony when the README is in English.