But "everyone" doesn't have the same keyboard nor does everyone speak the same language. ASCII is not a universal character set and treating it as such is nothing short of cultural imperialism: "If it's good enough for us, it's good enough for everyone".
Artificial limits on language and characters sets might sound simple to you but it introduces a lot of complexity for others. Unicode code solves that problem with not too much overhead.
Also, just to point out, this assumption is exactly why diversity in tech matters so much.
English is not my first language and my native language doesn't use Latin script, still all the keyboards that I ever saw supported entering ASCII characters. As far as I know all the keyboards that are in active use support English layout.
We shouldn't dismiss this as "cultural imperialism". Instead we should use this to our advantage. Currently source code written in China or in Russia can be read by developers in India or in the US. This is amazing. Let's not forsake it!
Agreed. Growing up in a country and at a time with personally accessible computers and very little literature, I was able to learn stuff that withstood the test of time and did not subject me to switching costs.
Already, differences in menus and keyboard shortcuts make the skills of trained office workers less relevant when they immigrate.
The proponents of translation tend to believe what they themselves or other translators will be clear to people just learning the concepts. That is most often not true.
> I am willing to bet the sentence “Çözümü SCALAR bağlamda veri döndüren scalar() fonksiyonunu kullanmaktır” does not make any more sense to a Turkish speaker who speaks no English than “The solution is to use the scalar() function that will create SCALAR context for its parameter.”
> Translation and hash-lookup are different things. If you want to convey meaning, you have to have a command of both languages, and the subject matter. Without that, you are only going to add to the word soup. Translating “big event” as “büyük okazyon” helps no one.
The availability of alternative commercial keyboards is possibly not the best metric to use to judge actual need/desire. There are a large number of non-ASCII layouts that can be mapped on top of a standard QWERTY[0] which show that ASCII is not a valid assumption for a modern general purpose programming language.
The idea that we should all be grateful for the unification that using one language brings is a sentiment that reinforces the idea that this is cultural imperialism. There are definitely benefits to conformity, no doubt, but imposing it unnecessarily is a design decision that should be questioned. Why take away options from people who might value that freedom?
> There are a large number of non-ASCII layouts that can be mapped on top of a standard QWERTY[0] which show that ASCII is not a valid assumption for a modern general purpose programming language.
I have seen multiple "foreign" keyboards. They all have ASCII labeled on each key. Using the QWERTY layout demonstrates the dominance of ASCII, which is a valid assumption that modern programming language can reliably rely on.
Please lookup in Image Search a Russian keyboard and a Japanese keyboard. What do they have in common? Right, besides the respective alphabets they have QWERTY Latin layout on them. Basically all of the keyboards can be used to input ASCII symbols out of the box.
I don't really care whether you call this cultural imperialism or not. What matters is that a whole industry can use the same standard worldwide. It's the same as metric system. We already have to deal with imperial system, imagine how much more painful would it be if every country used its own measurement system or its one calendar.
Agreed. My first language didn't use latin script--it didn't even read left-to-right. But I'm not offended that programming languages all do use latin script and a constrained character set.
>> The best thing about using only ASCII for the main syntax is that everyone can type it with their keyboard.
Well, some keyboard layouts make it harder though. I have spent a considerable amount of time trying to teach programming constructs over Zoom to budding developers in Japan over the past two years. The placement, access mode, and actual typing of characters such as `{`, `$`, `~`, `|`, `:` etc has been the biggest stumbling block during these sessions.
So, there the subset of ASCII that is equally easy to type on all keyboards is smaller than the full range of non-control characters.
> But "everyone" doesn't have the same keyboard nor does everyone speak the same language.
I like that Vim's digraph feature lets me solve the problem in my editor without having to rely on the keyboard layout or OS level preferences. So, typing these lines:
my $μ = "İstanbul'da hava çok güzelmiş";
say uc($μ);
takes the exact same keystrokes regardless of the OS/environment I am in:
m y CTRL-K m * = "CTRL-K \ I s t a
On my own machines, this has the advantage of not having to switch languages in the act of typing (although Win+SPACE is pretty easy on Windows, cycling through the five I have installed is not trivial). And, do I really remember where ø is on the Danish keyboard as opposed to where ö is on the Turkish keyboard?
> ASCII is not a universal character set and treating it as such is nothing short of cultural imperialism: "If it's good enough for us, it's good enough for everyone".
SI units like meters and kilograms are also cultural imperialism and we should return to diversity of units, ideally different one for each town. /s
That's the inverse. What we're talking about with keyboards is the opposite, some are advocating for more division. That's like starting a movement for scientists worldwide (who unflinchingly use metric even in the US, as far as I'm aware) to ditch metric and start using the standard units that were historically common in their culture.
And for what it's worth, I've never talked to a person who doesn't agree that the US using metric would be great, the problem is that getting over the inertia of the existing casual measurements is extremely difficult because even when metric is on the label, imperial is the emphasized one (the entire traffic sign infrastructure, the vast majority of cooking implements, decades of cookbooks, most food packaging, medical records systems, drivers licenses, advertising campaigns, the personal fitness ecosystem, entire product names and trademarks). 60 years ago maybe it could be doable, but at this point it's a bit of a lost cause without very much gain.
Given that the go community does not seem to hold this as a majority opinion, you might consider whether an editor translation layer could allow you to tailor your environment to your preferences while maintaining source-level compatibility with the broader go community.
If compatibility is not as important to you, privately forking the language is also an option, but that seems fraught with peril of your code dying with you.
But the point is not my preference to use the actual, proper symbols, but rather the technically unnecessary decision forced upon me that says I cannot.
This is just the English/Esperanto problem again. Do you do the thing that's the most fair or do you do the thing that's unfair but has the most benefits for everyone involved? Yes, it's unfair to limit people to ASCII but it's also the only way their code is going to see widespread engagement.
> it's also the only way their code is going to see widespread engagement
Wow, what a claim! I can see how this may have some anecdotal evidence behind it since programming has had such a strong English bias but it's conjecture to say that this is the only path. Not only does that claim lack evidence, it also lacks imagination. The future doesn't have to follow the same patterns of the past.
The technical constraints of ASCII have long been irrelevant and its only the cultural imposition that remains. While this has been the case the size and importance of computing has exploded everywhere (e.g. 4 billion people worldwide use the internet).
Can you really say with confidence that global "widespread engagement" is (and will always be) a desirable property for code projects? Is software produced in this way and at this global scale really likely to be better quality for everyone?
That's the brilliant thing about programming: you can do it however you want. If you want to write your code in such a way that an Anglophone spends half their time looking up ALT key combinations to type the characters, go ahead. I'm just saying that I'm not touching that code with a ten foot pole, nor is anyone I know, nor would any of my customers. There's too much talent in the world for me to put up with one iota more hassle than necessary.
What's the purpose of supporting other character sets in a language's syntax? Good luck finding contributors from all over the world for a software written in Turkish characters. I mean for hobbyists or very special purpose cases where such a thing is really needed (writing code in Turkish or Chinese or Arabic or whatever), people can add language support for that (after all it's just a bunch of keywords). It needs some effort but not impossible. People can also design programming languages with their own special character sets. It's wild to see someone objecting writing software in ASCII because of diversity/cultural issues. Really wild!
Not sure about Turkish, but I know for a fact that when you have a team of Chinese devs work on a Chinese software project Mandarin starts to show up in the codebase. And while usually it's written in pinyin (the standard Chinese romanization system) since most programming languages assume ASCII, it's obvious that those people could benefit from being able to use Chinese characters in place of ASCII and English.
If your argument is "sure, then let them invent/fork $LANGUAGE to suit their needs", just take note that if you're a language designer/developer that wants to see the language widely adopted, it's detrimental to have the attitude that ASCII is enough for everybody. There's no reason to have (for example) "Arabic-python" just because somebody insists on ASCII instead of UTF-8 even though there's little technical reason not to support it.
Non-ASCII characters make sense in national application domains, e.g. tax software, where you don’t want be forced to transliterate (or worse: try to translate) the non-English terminology.
Let’s be realistic 99% of software, weighted by value, is in English. This is a good thing. There are strong network effects, and fracturing the software world into multiple competing linguo-spheres would destroy economies of scale.
Would you similarly oppose the requirement that all civil aviation globally be done in English on the grounds of “cultural imperialism”?
> fracturing the software world into multiple competing linguo-spheres would destroy economies of scale
There is a very visible pattern in most Open Source projects where a small group of core maintainers will do most of the work even if there is a much wider body of causal contributors (see Nadia Eghbal's _Working In Public_). So, what are the economies of scale? Are you perhaps referring to problems experienced in the by-gone age of the early internet?
Economists largely agree that healthy competition is beneficial for improving quality, spurring innovation and reducing costs. I don't see the problem with multiple language/culture specific software projects that all solve the same problem. This could even look like different programmers working on different projects for different audiences.
The only downside I can see for the everyday programmers is the FOMO generated from inaccessible software in a foreign language. Isn't that ironic?
> Would you similarly oppose the requirement that all civil aviation globally be done in English on the grounds of “cultural imperialism”?
Do you think that every pilot on earth always speaks only English? No.
People should have the choice not to speak English and write their alphabets if they wish.
Enforcing ASCII on code is like enforcing ASCII on URIs, e-mail addresses. Unnecessarily restrictive to the rest of the world outside of the anglosphere. Of which there's a lot.
It requires proficiency when you want to go or receive international, but doesn't enforce it as the single language that could ever be used, e.g. domestically. There's no point in pretending there's some magic filter that would enforce it.
The Tower of Babel. If the source code is proprietary or for education then it doesn't matter, but for the open source world it'd mean division onto multiple different languages where no one can understand and learn from each other. No one is going to learn 5 different alphabets and 12 different languages just so they can understand the source code.
There is already open source software written in other languages.
Sometimes identifiers and comments are transliterated into ASCII, sometimes they remain in the original script.
Of course, they won't get many contributions from English speakers. They will get more contributions from speakers of that language. That decision is for the project to make, not others to impose.
Realistically, English will still the lingua franca for software in the short-term future, and I don't think anyone is saying we should change this. The thing is, for many people "interacting with the worldwide programming community" is not a thing they need.
Imagine a computer class teacher in (for example) China teaching primary school children. Why should they need to learn English before starting to write "Hello world!" (or rather, 「你好世界」)
In an alternate universe the lingua franca of programming languages is Chinese, would you still make the claim that it's better to take away choices and force ALL programmers into using the existing lingua franca regardless of their background?
I'm guessing you'd be crying cultural imperialism because you can't teach your 6 year old kid programming in your native language.
> If the source code is proprietary or for education then it doesn't matter
I'm not forcing you to speak and teach children in English. My country actually was under cultural imperialism and people back then weren't allowed to speak or learn in our native language. And you make it sound like a joke, but whatever.
Artificial limits on language and characters sets might sound simple to you but it introduces a lot of complexity for others. Unicode code solves that problem with not too much overhead.
Also, just to point out, this assumption is exactly why diversity in tech matters so much.