Can programming become language-independent? Will we always program in English? Will we ever be able to program in our local languages? Is there any research that addresses the matter? Are there any such developments?

closed as too broad by gnat, durron597, user40980, Ixrec, user22815 Oct 10 '15 at 22:26

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Ask yourself: Would it help you in any way? It wouldn't help me (I'm not a native English speaker). – user7043 Dec 24 '10 at 13:46
  • Will your native language used for development help you !?! – user11020 Dec 24 '10 at 14:12

There have been attempts to introduce programming language flavors translated into a local spoken language around the globe. They however never came to be more than experiments.

Some customer-oriented languages are localized like Excel macros language. But these are really end-user oriented.

Programmers will always need something universally understood. For now it is English.

Will we ever be able to program in a language other than English?

Unlikely. For a simple reason there is no advantage to it. The programming language itself, there is not that much linguistic content within so it's possible for everyone to learn a few English keywords.

But the rest has to be understood worldwide non-ambiguously. Compiler output, error messages, documentation for tools and libraries. It's important for worldwide knowledge sharing and exchange.

Additionally, in the times of globalization and distributed teams there has to be the one and only language for comments in code, documentation and collaboration. Tech articles, blogs, books. International conferences. People need to understand each other otherwise things get unnecessarily complicated.

  • Compiler output, error messages, documentation for tools and libraries. I've had some problems searching for localized output (from Visual Studio, IIRC) in the web. It's not always easy to translate the output to it's exact original. I can't agree more with that. – kaoD Jun 4 '12 at 1:33

As a matter of fact, programming already is as "language independent" (I suppose you wanted to say "natural language...") as it gets. You see out of 3-4 thousand languages spoken today on Earth, it only depends on one major natural language, that is English.

Imagine what would it look like if the dozens of major programming languages in use today were based on Swahili, French, Swedish, Russian, Slovak, Bosnian, Hungarian, Spanish, Catalonian...?

How would anyone not understanding these languages (all are admittedly by far harder than English in grammar) be able to make even a modest career advance, or just keep one self up-to-date. English today is what Latin used to be 2,000 years ago. Actually I dare say it delivers the promise of Esperanto without the hassle of reinventing the whe.. err.. the language.


Answer to philosophical part of your question:

You think and you program in abstract categories and ideas, neither in English, nor in Java or C++. All those are just mediators. English, as Jas mentioined is his answer, is a the most convenient because most programmers speak or understand it.

Answer to technical part of your question:

Classic compiler consists of language-specific frontend, language-agnostic optimizer, and hardware-specific backend. Once you create a consistent and efficient natural language frontend (say, for GCC), the compiler will be able to generate the code. The neuance is, once such parser is developed, programmers won't be needed any longer. Only managers (to manage computers). But the complexity of natural language recognition domain is so high that I hope the problem won't be solved any time soon.


English is the lingua franca of programming, like Latin for doctors.

Consider why you want alternative keywords and then consider what you Will have to give up.


I think it is very hard to program without the english keywords / functionnames and also, without the concepts they bring. Because many of the concepts are learned from English resources. Finding a translation will not make things easier, because you have to learn the concepts anyway. When working with a local flavor of Excel, I couldn't for example get used to something different than 'if'. Because 'if' is across all programming languages and is hardwired into my brain by now. ('If' being a simplistic version. But it goes to memory allocation of cpu cycles - those are domain specific terms so they are new for anyone who doesn't know the domain, and those who know it will know the english terms anyway.)

But I do not think that you are only programming abstract principles. When writing applications or datamodels, you relate to 'the real world', and then it makes sense to pick names that describe what they relate to out there, and sometimes, those concepts are only useful in your own language because they refer (for example) to legal terms.

So some point or other, languages will cross.


It certainly could, but it would require a change in the way we write programs. Currently, we are wedded to a "write text file, give text file to computer" model of software development. Every programming system works like this, and this makes it very difficult to make it language independent. I don't think it is the only way, though.

Long ago, on small machines, it didn't always work this way. On very low memory computers (think 16K Commodore PET) it wasn't reasonable to store the entire text in memory of a program. Even a trivial BASIC program would have exhausted memory if "GOTO" took 4 bytes. So these systems tokenized input as you typed. You typed "GOTO" and that was immediately translated into a token. When you listed your program and tokens were converted back to human readable keywords.

In such a system, creating an alternate language would be trivial. English speakers would see "GOTO" and Japanese speakers would see "行く" and since the conversion happened at the code creation/display time, English and Japanese speakers could share source. The source itself would be tokenized. I see no reason why you couldn't do this with modern languages.

What it would require would be to break the "text file as source code" model. The language would have to be completely integrated into the editing process. In this imaginary world, when you fire up your editor and load, say, Python source, all of the language independent tokens in the file are translated to your locale language setting keywords. When you type keywords they are automatically translated to tokens. In other words, you aren't directly editing the text but rather creating the tokenized file. The interpreter would then be written to operate on tokens rather than text. It would probably even make interpretation/compilation a little faster as everything would be tokenized at the editing stage.

This is all possible and would have some advantages. What you'd lose is the ability to read source using arbitrary text editors. It would require language aware editors. When I was in college, I wanted to build a system like this, but real life intruded.

Of course, this doesn't solve everything, which is probably why it has never been done. Keywords might be language independent, but identifiers and constants wouldn't be. It might not help much if the code looked like this:

for(unsigned int 人=人リスト.begin();人!=.end();人++)

This probably doesn't just effect user written code but also libraries. In the above, begin and end aren't language keywords, but library methods. To solve that, you'd need machine translation, and we're not there yet. As an English speaker who has on occasion read C++ code written in Japan, I can say the fact that the language keywords are in English only helps marginally.