40
$\begingroup$

Every programming language I know (Java, C++, C#, Python, etc.) are all made in English. That is, you can't, for example, type imprimir("hola") instead of print("hi"). You have to use English words for all programming keywords.

Why are almost all programming languages based on English?

$\endgroup$
16
  • 26
    $\begingroup$ List of counterexamples, although I still think the question is a great one. Welcome to PLDI! $\endgroup$
    – Seggan
    Commented Jan 28 at 3:03
  • 6
    $\begingroup$ The question is essentially answered in the first paragraph of the above Wikipedia page. $\endgroup$
    – Barmar
    Commented Jan 28 at 3:52
  • 5
    $\begingroup$ @SlightlyPsychotic While there are many counterexamples, none of them have anything near the popularity of the English-based languages. I'd guess that 99% of software is written in less than 10 languages, and they're all English. And the reason is likely that most development of computers and programming languages occurred in English-speaking countries (primarily US and UK), and in the last 50 years English has become the lingua franca of the global economy. $\endgroup$
    – Barmar
    Commented Jan 28 at 3:58
  • 20
    $\begingroup$ Microsoft Excel went a different way, and it's extremely frustrating, because if I have a simple table with a simple SUM in it, if I open it on a version of Windows with a different language, it does not work, because it expects the local language's word for the sum. $\endgroup$
    – vsz
    Commented Jan 29 at 6:20
  • 4
    $\begingroup$ We tried it in Visual Basic 3 or 4, I don't recall which. Since the code was stored as a token sequence, we would detect if the user was running, say, French Windows and display the code using French functions and keywords. It was a NIGHTMARE for testing and even worse for documentation, and users didn't really want or need it. Non-native speakers of English adapt quickly to the keywords. $\endgroup$ Commented Jan 30 at 20:21

8 Answers 8

29
$\begingroup$

I think the primary reason for this is the same that motivates any other lingua franca: the desire to exchange ideas across different groups.

We can group the places where natural language is used in programming into a few different categories:

  1. Keywords - terms baked into the syntax of the language ("if", "return", "while", etc). These are what linguists would call a "closed word class"; they may be reserved from use as identifiers, or marked out with stropping.
  2. Built-in identifiers - names of functions, namespaces, classes, etc, which are part of the "standard library" of the language. These are generally an "open class", in the sense that new items are added reasonably regularly, and can move somewhat freely between this and the next category.
  3. User-defined identifiers - this is the much largest list, and also the one over which languages designers have least direct influence. The main limitation placed is the available character set - if identifiers can only use the Latin letters in ASCII, some languages will be harder to use (though not impossible).
  4. Error messages and other output. This generally depends not on the design of the language, but its implementation. These may be the same thing (e.g. PHP has only one widely used implementation), or entirely separate and widely varied (e.g. C compilers).
  5. Documentation. On the face of it, this is the easiest to translate, and for example the PHP manual is currently "fully" translated into 9 languages.

Of these, the vast majority of code that looks like language is user-defined identifiers. These can be, and regularly are, written in the user's first language - except when they're shared. If a new online service wants to publish an SDK on a package repository such as CPAN, NPM, Packagist, Nuget, etc, they need to define a public API for that package, and that involves choosing identifiers. If the majority of packages on that repository use identifiers in the same language, that is a lingua franca in exactly the same way as the trade languages of the ancient Mediterranean, or the Latin of Renaissance scientists.

This then leads back to the choice of built-in identifiers. The language designer could, in principle, provide multiple aliases for every built in function, giving the user a choice of languages. However, this becomes a wasted effort if the user community picks one as the lingua franca for sharing code samples and libraries.

As we get deeper into the core of the language, and particularly with keywords, we get a similar effect between languages: if you want new users to pick up your language, there is an advantage to them recognising parts of it. This leads to certain terms becoming somewhat standardised in their meaning - the lingua franca is based on a particular natural language, but becomes its own thing. For instance, the "return" keyword originated from the intransitive English verb meaning "go back", but has acquired programming-specific meanings: "returned value", "return type", and so on.

To circle back to error messages and documentation, like private identifiers these can be and often are translated; but they will still have to incorporate large parts of the lingua franca, to mention keywords and identifiers which are not translated.

All of that leaves us with a few situations where not using the lingua franca would be reasonable:

  • Where the language has no "open word class". For instance, Microsoft Excel has localized names for all its built-in formula functions.
  • Where the language isn't intended for writing code to share. The biggest example of this is educational languages: the main aim is to make it easy for users to write their own programs, to learn programming concepts.
  • Where the audience for the language is limited to a particular community. The macro language of an internal tool might exclusively use the local language of its developers, although the draw of the lingua franca will still be there from exposure to other languages.

Throughout this, I've deliberately talked about the lingua franca in the abstract, because the fact that it is based on English is largely historical accident: English was the language in the UK and USA where major early computer science work happened; and it's also a lingua franca in other contexts, meaning it is accessible to a lot of users as a second language.

$\endgroup$
8
  • 1
    $\begingroup$ I think you forgot "comments" and "application/library documentation" $\endgroup$
    – Bergi
    Commented Jan 28 at 17:34
  • $\begingroup$ @Bergi True; I guess d"ocumentation" can be broken down almost in parallel to code: core language documentation, third-party public API documentation, and internal documentation such as comments. $\endgroup$
    – IMSoP
    Commented Jan 28 at 17:51
  • 7
    $\begingroup$ I've worked with native Russian speakers who say they prefer to program in English, since it feels to them like a self-contained "programming" way of thinking and speaking. (They were incredibly talented developers, by the way.) $\endgroup$
    – Roy Tinker
    Commented Jan 29 at 19:50
  • $\begingroup$ @RoyTinker Excel uses localized function names, and it's always "fun" to have to figure out how they've decided to call VLOOKUP in Polish (it's WYSZUKAJ.PIONOWO if you're curious - and you thought T_PAAMAYIM_NEKUDOTAYIM was bad...). To me it's not so much "programming mode" as "there's so much English in software development that it's easier to fully switch over than constantly switch your brain between two languages". $\endgroup$ Commented Jan 30 at 16:35
  • 1
    $\begingroup$ I don't think English being the lingua franca is historical accident, since the amount of computing research reflects the global power of the US and UK. $\endgroup$
    – qwr
    Commented Jan 31 at 4:18
36
$\begingroup$

The influence of momentum

The first "compiled" programming language was Autocode, developed at the University of Manchester in England in 1952. The first widely used programming language, FORTRAN, was developed at IBM in 1957, in the USA. The first example of a non-English programming language I can find is the ALGOL 68 standard, which was published in several European languages, and eventually Japanese.

By this time, however, the USA and UK had already established themselves as the pioneers of programming language development, with languages like LISP, BASIC, COBOL, and ALGOL58. From there, every notable language was in English because the people who made them spoke (possibly amongst other things) English. If you want your language to be both useful and popular (as many do), it makes sense to target the demographic with the largest chance of using your language; for a long time, this was English[1], and even as countries like India and China have become large centers of development in the tech world, this continues to be English. I have no doubt that at some point we will see a popular non-English language, but momentum rolls on.

[1]: By "English", I mean "People willing to program in English"

$\endgroup$
8
  • 14
    $\begingroup$ Along with all this, I think it's worth noting that it doesn't seem particularly hard for a lot of people without English fluency to learn to program using English keywords. One of my favorite languages, Ruby, originates in Japan, has many Japanese-speaking maintainers and users with limited-to-no English skills, and has better and more comprehensive official docs in Japanese than English as well as lots of cool Japanese books on the language that don't get translations, but still it uses English keywords. I think this makes it easy for the intertia/tradition of English to win out. $\endgroup$ Commented Jan 28 at 20:30
  • 8
    $\begingroup$ A lot of the english keywords, like for...in or do...while actually have much more limited scope in meaning than in English, where a word could have 20 different meanings. $\endgroup$
    – qwr
    Commented Jan 29 at 2:52
  • 1
    $\begingroup$ @ZoëSparks great point, I'm sure I could learn to program with keywords like nachat and yesli as long as I get to use English for identifiers. The fact that most operations are symbolic helps too $\endgroup$
    – Seggan
    Commented Jan 29 at 3:53
  • $\begingroup$ @ZoëSparks Hasn't Japan required children to learn English in school for decades? By the time Ruby was developed, I'd expect most programmers to have gone to school with that requirement. Even if they're not "fluent", they would be familiar enough to understand the programming words. $\endgroup$
    – Barmar
    Commented Jan 29 at 16:06
  • 3
    $\begingroup$ @Barmar Yes, but (having lived there as an exchange student on homestay + attended high school, and having spent lots of time on Ruby bug trackers and mailing lists and reading Japanese-language blog posts and books and things about it) I can say that English proficiency among adults there varies widely. It's a bit like Spanish knowledge among Anglos in my home state of Texas: most learn some in school, and a few attain fluency, but as adults many recall only a few words or simple phrases even if they took classes in school for years. Many people around the world know that much English. $\endgroup$ Commented Jan 29 at 21:51
9
$\begingroup$

Historical roots. Much early development of computers and programming languages was done in English-speaking countries. ENIAC and UNIVAC were American. The Manchester Mark 1 was British. Fortran, COBOL, Lisp, and BASIC were all developed in the United States. ALGOL was the first significant international collaboration, but by then the USA was dominating the industry.

And once English became the lingua franca of the computing industry, developers from different linguistic backgrounds also designed programming languages in English, for the sake of having a global standard. Python's BDFL may be Dutch, but Python's keywords and standard library are named in English, because that's what's familiar to programmers.

Also, English has some technical advantages for designing a programming language, compared to other human languages:

  • English has a simple alphabetic writing system. (True, English is infamous for its orthography not accurately representing its pronunciation, but that's irrelevant when typing source code to be processed by a computer.) It can be written in 7-bit ASCII, with the rare “decorative” diacritics simply ignored. We don't have thousands of characters like in Chinese or Japanese. We don't have context-dependent letter shapes like Arabic. We don't need support for bidirectional text. That makes character encoding and font support straightforward.
  • English has relatively little grammatical inflection. For example, you can give an instruction to “print this text”, and the form of that command doesn't depend on whether you're talking to a man, a woman, a group of multiple people, or an inanimate object like a computer. So in a programming language, you can just name a function print, without caring which “gender” your computer, printer, or text is.
$\endgroup$
4
  • $\begingroup$ Can you give an example where inflection might be needed? This escapes my imagination, probably because I speak non of the other languages you mention. In my (English) programming, this only ever came up when pluralising variable names (and English already has some weird plurals). $\endgroup$
    – Bergi
    Commented Jan 29 at 19:28
  • 3
    $\begingroup$ @Bergi: Arabic is one such language. The imperative form of “print” can be atabae (to a man), atabei (to a woman), atabaeuu (to a group of men), or aitabaeuu (to a group of women). Spanish doesn't have gendered imperatives, but still distinguishes formality and plurality with imprime (tú), imprima (usted), and impriman (ustedes). $\endgroup$
    – dan04
    Commented Jan 29 at 20:21
  • 2
    $\begingroup$ Good point about English having some objective linguistic advantages. The technical term for your last paragraph is that English is more "analytic" than many languages; although it is not completely analytic, e.g. nouns vary to indicate plural vs singular. $\endgroup$
    – IMSoP
    Commented Jan 31 at 16:14
  • 1
    $\begingroup$ "Professor, the program is refusing to compile on my computer" "Have you addressed it with the correct pronouns?" $\endgroup$
    – Seggan
    Commented Feb 1 at 18:27
5
$\begingroup$

For English I assume it means a global language. For why English has become a global language, I think it's more of a question about history, instead of PLDI. Here I answer why a programming language would choose keywords from a global language.

Firstly, as Seggan commented, there are a lot of programming languages using other natural languages. But it is much less likely someone would get to know a programming language not in either English or their first language. If you use English, you have a much broader user base, that could potentially get your language much more popular. If someone wants a broader user base, they would also choose English. So, in the end, the most popular programming languages you have known are in English.

I think there are only two alternatives for this purpose. One is to make it multilingual.

There were some animation makers and game designers that had a way to make easy programs using a GUI list of commands, and the commands tend to be translated. It's easy because the translation doesn't change how the code is stored, but only how they are displayed. But users switch to the traditional way quickly, because the graphical way usually only support a restricted set of features, and the editor isn't very easy to use. Better examples on this direction would be Scratch-like languages. I don't know Scratch much, but I think it's much more powerful than the GUI lists, but still not as powerful as modern advanced languages.

The obvious problem of supporting multiple languages in traditional text programs, is the identifier names could easily conflict with keywords or system libraries in a language that the programmer doesn't know, or not even existed before the program has created. It might be better if the programmer chooses the language. But there is another problem, that translations tends to be slower than the original release, and if it's not the original developer making all the decisions, sometimes translations are bad and are subject to change, which would be very undesirable to use in a programming language. The programmers could use English before the translations are stable, but they would still have to learn the English version, adding more difficulty to just use English, and they would need an automatic translator to change the language afterwards. A potentially better way would be like the GUI lists, that only translate the words in the editor. In either case, I think they are not considered reliable operations for program source code, especially with eval and homonyms in consideration.

But I don't think these difficulties are absolutely unsolvable. Maybe someone could come up with some clever ideas. And they could start from languages that least likely conflict with English. I think the real problem is, keywords are not the only thing in a programming language. Documentation and libraries matter more. A translated programming language is of no use, if there are not documentations at all. And not many language designers had the resources to maintain documentations in that many languages. Library writers usually had less resources. That also answers why there had to be a popular programming language, instead of everyone using their own programming language in their own country: Actually there is not much reason for a programming language. You could do it if you had enough funds. But the reason is strong for libraries, and languages don't affect that much without libraries. A possible middle ground is, make everyone use their own language internally in a project, and export the symbols in English, to make a library popular, cost-effective, and non-English. But it might be difficult for us to know it is the case.

TL; DR: The majority of libraries would support only one language, and you'll not know it if it is not English. Programming languages doesn't contribute much to the whole picture, but have extra difficulties, that may not worth it.

Another way is to use symbols, like APL. But that only applies for a small set of builtins. They still have to use words in natural languages if there are a lot of libraries.

Also note that while programming languages borrow words from natural languages, they are not the same. Some words like "for" "yield" are too generic but have gained much more specific meaning. But they may not affect translation.

Survey about the documentation languages in some programming language's homepage

Python has English, Spanish, French, Japanese, Korean, Brazilian Portuguese, Turkish, Simplified Chinese, Traditional Chinese, 8 or 9 languages

PHP has English, Brazilian Portuguese, Chinese (Simplified), French, German, Japanese, Russian, Spanish, Turkish, 9 languages

Rust has English (en-US), Español (es), Français (fr), Italiano (it), 日本語 (ja), Português (pt-BR), Русский (ru), Türkçe (tr), 简体中文 (zh-CN), 正體中文 (zh-TW), 9 or 10 languages

Ruby has Български, Deutsch, English, Español, Français, Bahasa Indonesia, Italiano, 日本語, 한국어, polski, Português, Русский, Türkçe, Tiếng Việt, 简体中文, 繁體中文, 15 or 16 languages

C# has Bahasa Indonesia, Bahasa Melayu, Bosanski, Català, Čeština, Dansk, Deutsch (Österreich), Deutsch (Schweiz), Deutsch, Eesti, English (Australia), English (Canada), English (India), English (Ireland), English (Malaysia), English (New Zealand), English (Singapore), English (South Africa), English (United Kingdom), English (United States), Español (México), Español, Euskara, Filipino, Français (Belgique), Français (Canada), Français (Suisse), Français, Gaeilge, Galego, ქართული, Hrvatski, Íslenska, Italiano (Svizzera), Italiano, Latviešu, Lëtzebuergesch, Lietuvių, Magyar, Malti, Nederlands (België), Nederlands, Norsk Bokmål, Polski, Português (Brasil), Português (Portugal), Română, Slovenčina, Slovenski, Srbija - Srpski, Suomi, Svenska, TiếngViệt, Türkçe, Ελληνικά, Български, қазақ тілі, Русский, Српски, Українська, עברית‏,‎ العربية, हिंदी, ไทย, 한국어, 中文 (简体), 中文 (繁體), 中文 (繁體 香港特別行政區), 日本語, 48 or 69 languages

Scratch (user languages) has Аҧсшәа, Afrikaans, العربية, አማርኛ, Aragonés, Asturianu, Azeri, Bahasa Indonesia, বাংলা, Беларуская, Български, Català, Česky, Cymraeg, Dansk, Deutsch, Eesti, Ελληνικά, English, Español (España), Español Latinoamericano, Esperanto, Euskara, فارسی, Filipino, Français, Frysk, Gaeilge, Gàidhlig, Galego, 한국어, Hausa, Հայերեն, עִבְרִית, हिंदी, Hrvatski, isiXhosa, isiZulu, Íslenska, Italiano, ქართული ენა, қазақша, Kichwa, Kiswahili, Kreyòl ayisyen, Kurdî, کوردیی ناوەندی, Latviešu, Lietuvių, Magyar, Māori, Монгол хэл, Nederlands, 日本語, にほんご, Norsk Bokmål, Norsk Nynorsk, Occitan, ଓଡ଼ିଆ, Oʻzbekcha, ไทย, ភាសាខ្មែរ, Polski, Português, Português Brasileiro, Rapa Nui, Română, Русский, Sepedi, Setswana, Slovenčina, Slovenščina, Српски, Suomi, Svenska, Tiếng Việt, Türkçe, Українська, 简体中文, 繁體中文, 76 or 80 languages

$\endgroup$
6
  • 9
    $\begingroup$ I think most of the C# documentation is automatically translated, and rather badly. It's almost always better to read the original English one. $\endgroup$
    – Bergi
    Commented Jan 28 at 17:41
  • $\begingroup$ "简体中文, 繁體中文,": "Oh, we got both kinds: Country and Western!" $\endgroup$ Commented Jan 29 at 11:42
  • $\begingroup$ @Peter-ReinstateMonica That's the reason for the "a or b languages". C# has 10 kinds of English which I doubt they all have some differences. $\endgroup$
    – user23013
    Commented Jan 29 at 11:49
  • $\begingroup$ @Bergi And that means serious translated documentations of a traditional language would be much less likely to have a number that matches Scratch. $\endgroup$
    – user23013
    Commented Jan 29 at 11:54
  • 4
    $\begingroup$ Goal for translation, automatic or not, should be that the average native speaker of the language understands the translation better than the untranslated original. That is very often not the case. Once had a video recorder with German manual that mentioned a button for saving the light of the day (in German). I had to translate it back into English to figure out it was daylight saving time (DST). In proper German it is just “summertime” vs “wintertime”. $\endgroup$
    – gnasher729
    Commented Jan 29 at 19:18
4
$\begingroup$

The basic explanation is firstly that English is a widely spoken language around the world, and secondly that most computer technology has originated and continues to originate from America, where they speak English.

Moreover, post-WW2 America became a centre in the world for scientific research of all kinds, so that the technology doesn't just originate in America but so do a lot of the ideas, terminology, and standards, and the academic institutions that gestate them.

Scale is important too. Not only does America itself speak English, but so do a number of its major allies and trading partners who have equally advanced economies with demand for computerisation. This means that a large mass of English-speaking professional workers, and technical artefacts and tooling in English, have already been accumulated, completely dwarfing what was ever available in any other language.

So if a company wants development done today, the biggest pool of resources are in English. Even if you hire developers who speak a local language, they are likely to have to also speak English to access the existing resources just to learn their trade in the first place, let alone continue to practise it commercially.

Since the internet, there is also a huge "hive mind" of practitioners worldwide who can be consulted on difficult problems. These practitioners are either native English, or speak English as a lingua franca. This means practitioners have to carry on speaking proficient English regularly in order to consult with this hive mind.

Once all that investment is sunk in English-centric learning and speaking, there's usually very little to be gained, commercially, from diverting things back to the local language.

Only nation states with a political policy on language, and with an enormous commitment of economic resources, could really hope to challenge this dominance of English, but none yet have seen fit to do so.

$\endgroup$
2
$\begingroup$

Many programming languages inherit reserved words such as if, else, and while from other programming languages, with semantics that are also inherited from those other languages, rather than from English per se. If a programming language were to have reserved words providedThat and asLongAs, and the semantics of construct like:

asLongAs (x < y)
{      
  providedThat (func(x) > 3)
  {
    action2();
  }
  action3();
}

were intended to match those of C's while and if constructs, the use of asLongAs and provitedThat instead of while and if would make the meaning less clear, even to people who would have no trouble understanding the English meaning of the phrases "as long as" and "provided that". If someone who spoke a different human language were to have it use that language's phrasing for "while" and "if", the same issues would apply.

If a programming language is going to have some reserved words that correspond with English-based reserved words that exist in other language, basing other reserved words on English words or phrases would generally make code seem more consistent than arbitrarily mixing in foreign words. If, however, a human language had a single word that would naturally describe a concept that would take multiple words in English, a programming language might benefit from using that word, especially if the single word would fit the semantics of the construct better than any practical English-language phrasing.

$\endgroup$
1
$\begingroup$

There are real problems with compatibility once one steps outside of "ASCI and related territories".

The best example I know is LaTeX: it is technically a language for typesetting mathematics, not a programming language proper.

Now, any LaTeX document containing an "Umlaut", i.e. ä instead of "a, does not always compile for non-German users. Same for French accents, Spanish tilde, etc. This problem is exponentially worse when a non-Latin alphabet is used. I recall being unable to get "LaTeX in Japanese" going on my mac as late as 2010. In turn, simply printing PDFs produced by standard LaTeX on a Japanese printer, was already a challenge.

I also recall the Underhanded C contest making use of similar-but-different letters to introduced security holes. This would be much worse if there was not "Standard English".

$\endgroup$
3
  • $\begingroup$ the attack described in the last paragraph is called script spoofing: en.wikipedia.org/wiki/IDN_homograph_attack $\endgroup$
    – qwr
    Commented Jan 31 at 4:07
  • 1
    $\begingroup$ From what I remember, PdfLaTeX was notoriously difficult for supporting other scripts, while XeTeX and LuaTeX, Unicode characters work perfectly fine. tex.stackexchange.com/questions/618009/… $\endgroup$
    – qwr
    Commented Jan 31 at 4:09
  • $\begingroup$ In my limited worldview, PDFLaTeX is still (most) widely used; the other ones being (much) more niche. $\endgroup$ Commented Jan 31 at 11:04
1
$\begingroup$

America has been the center of technology in general and computer related technologies in particular since the second world war.

The first decades after the war coincide with the development of the first widely used programming languages, which consequently happened in America or in international teams with American participation, in English, without giving it much thought. Most people working in the field speak enough English to at least read programs with English keywords and basic documentation, which made it easy for them to latch onto that development (surely easier than, say, a development in Mandarin, Spanish or Hindi, to name other widely used languages.)

Obviously, that made English a great choice for keywords in newly conceived languages, even though for the past 10 or 20 years the number of programmers whose mother tongue is Mandarin may have been larger than the number of those with English mother tongue. Close to nobody outside Asia speaks Mandarin; almost everybody with a college education speaks some basic English. English is the lingua franca.

And then there is great value in knowing the meaning of "for loop", "if clause", "assignment" or "statement"; computer science has developed a jargon much like medicine or jurisdiction which makes communication efficient and clear. Any non-English implementation would need a glossary with definitions which most likely would have to refer to the English originals in any case.

$\endgroup$
6
  • $\begingroup$ @12431234123412341234123 I'll translate your comment for the general public: "It is simply wrong that America has been the center of computer related technology since the 1950s -- Taiwan would be a better candidate (today, not 1950)." It's possible that the U.S. has lost their dominating position recently -- in 2022, for the first time in decades, IBM did not file most IT patents (Samsung did). But the current contender would probably be Korea (with Samsung and LG), not Taiwan. In other metrics (labor force, revenue) I suppose the U.S. is still ahead of the tigers. $\endgroup$ Commented Jan 29 at 10:55
  • 2
    $\begingroup$ As mentioned on the main question, content on non-language-focused StackExchange sites is required to be written in English. Therefore, any further non-english comments on this answer will be deleted. $\endgroup$
    – lyxal
    Commented Jan 29 at 12:34
  • 1
    $\begingroup$ [Citation Needed], whilst I agree that America has had some impact on the computing world, this seems to completely ignore the efforts of British companies, notably Dennis Ritchie, Creator of C. $\endgroup$
    – ATaco
    Commented Jan 31 at 1:00
  • 1
    $\begingroup$ @ATaco from my brief reading, it looks like Ritchie did all his research work at Bell Labs in New Jersey? $\endgroup$
    – qwr
    Commented Jan 31 at 4:13
  • $\begingroup$ @qwr Oops, that he did. I got my Bell Labs confused $\endgroup$
    – ATaco
    Commented Jan 31 at 4:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .