[yshklarov]

This is by no means unique to programming. Many areas of knowledge are less accessible to those who don't speak English, and much more so to those who don't speak any of the dozen major languages. Because of this, many people will simply learn (enough) English. It's not such a big deal.

In my view, having a single lingua franca is nice. It better facilitates knowledge transfer. I wouldn't want to see a fracturing where each area of knowledge (or, say, every specialization/application programming) is best treated in a distinct linguistic community. That would be bad for everyone.

[jayathra]

I see your point - having a global language certainly helps with knowledge transfer, and English has become that standard for programming. But is learning English really 'not a big deal' for everyone? For someone with limited access to quality English education, it could take years before they’re comfortable enough to learn programming effectively. Meanwhile, a fluent English speaker can start coding right away.

Rather than fragmenting knowledge, what if we had a system that let people write and learn code in their native script, while still maintaining full compatibility with the existing programming ecosystem? Similar to how Unicode enables multiple languages on the web without breaking global communication. Do you think that could work?

[Jtsummers]

https://en.wikipedia.org/wiki/ALGOL_68#Example_of_different_...

Algol 68 offered that, for keywords at least. Variables, procedure names, and the contents of strings can't be localized quite the same way (though localization for content is easier now than it used to be if you don't embed the string text directly in the source).

If we switched from a text file based representation of code to a different structure, localization could be performed more easily for source code even down to comments and variables. However, this would help you to work on a project I started, taken too far it would not help us work together (we'd refer to the same variables and procedures with different names). We'd still need to select a common language when collaborating.

Other languages, today, at least work well with unicode source but they retain English-based keywords (Go, Rust, probably others but they like to tout it specifically).

[jayathra]

Localizing everything could make collaboration harder if different people refer to the same function by different names.

But what if we had a system where people wrote code in their native script, and it automatically translated into a universal format when shared? Would that help keep things accessible while maintaining collaboration?

[Jtsummers]

That's what I suggested, but it means our person-to-person collaboration becomes more challenging, though if we work at arms length with each other it might be more feasible. You always work in your translated code, I always work in mine. But direct communication about code breaks down because we need to have a translator and decide on the common terms.

We could probably collaborate at a higher level (system architecture and design). I'm building a compiler, I can share the architecture with you and have you implement a particular optimization pass. But if I want to read your optimization pass code and discuss it with you then one of us has to learn the same code twice: once in our native language and once in whatever is decided to be the shared language.

Store the code in a database (or something akin to one) and use a structured editor and this mode is technically feasible. It would open up work for people who are not native in the original language, but you also need to ensure that code has a translation. So you're still going to need someone (or something) to do the localization as well.

OSS projects can't afford this, but commercial efforts might be able to. On the other hand, commercial projects can afford to be the $2/hour extra (companies are cheap bastards) to hire those English speakers in your country and ignore the non-English speakers.