I know this is a joke. But.. when I learnt C programming, and in order to smooth transition from algo classes to practical programming, we were told to #include a header file that would more or less do what this does for rust. The header file would also enforce curly braces and parentheses when writing loops or condition statements, as far as I remember. Fact is: it actually helped. Problem: my first foray in the industry would involve C and guess what? They used english-C (sorry no better word for it) rather then french-C. I fought for a few weeks re-learning the language.
As a monolingual English speaker I often wonder about the subtleties of this dynamic among newer developers.
Is the difference in cognitive load among folks who speak different languages is consistent or even measurable? Does it bias a developer toward any specific pattern/mistake/misunderstanding/bug? Are there subtle mental-model-building advantages to decoupling software commands from their linguistic meaning through a language difference even if it's initially more difficult? Does the presence or quality of English instruction affect adoption of development beyond the first few weeks?
Could be cool to explore these things to see how they might inform pedagogy or even language design. Then again, my relatively naive suppositions might lend entirely too much weight to it.
To non-native English speakers, who often write variables and function names in their language, the language difference between keywords and the rest of their program acts as a kind of pseudo syntax highlighter: it's very easy to spot language keywords because they're in English.
Secondly the keywords don't really have any strong prior meaning to overload, so in a way they're more "pure" cognitively and easier to grok. The word "for" in everyday English really has nothing to do with "iterative loop with variable definition", the word "use" has nothing to do with symbol imports, but that's all it means to a non-English coder.
Now libraries are another thing. Typically they start using higher level abstractions that start to map to everyday constructs (eg, in a drawing library you might find things like "stroke width" which are trivial to understand for a native speaker)
> Secondly the keywords don't really have any strong prior meaning to overload, so in a way they're more "pure" cognitively and easier to grok. The word "for" in everyday English really has nothing to do with "iterative loop with variable definition", the word "use" has nothing to do with symbol imports, but that's all it means to a non-English coder.
I would disagree with this. A lot of programming keywords have enough context to help new people. I.e. "for" or "forEach" maps almost perfectly to English. "For each friend you know, call them and ask what their birthday is and what kind of cake they like".
While loops are the same way. "While there's still boxes on the truck, you need to be moving those boxes".
It requires some slightly awkward contortions, but you can phrase English so that it somewhat resembles code.
"Use" and "import" both also have relatively clear parallels in English. import meaning bringing something from a foreign space into your own, and "use" being equivalent to using a tool.
English is my only real language (other than horribly botched Spanish) and the similarities to English really helped me when learning Python. Both in understanding and just simply remembering the keywords.
For a lot of new shops in at least western countries, writing everything in english is becoming the norm, including technical docs and comments.
The two main points I’ve seen are:
- it’s a daily pain to handle two vocabulary sets and lead to undue errors and bugs. When you have a “FishingBoat” class which related to a “boat” table and all the documentation points to “Bateau de pêche” and “barque” it’s 2x harder to follow things. Then people will accidently translate “bateau” to “ship” and it slips through a few reviews of mostly independent features, and you’ll have both words in the code base before you realize.
- it becomes a swamp the day a non native speaker touches your code base. For instance you need to share part of it with a company next door that happens to be the other side of the border. Or you ask a Romanian dev team to port your code to another platform.
Yes, that is a huge problem I have seen often here in French speaking Quebec. Developers will prefer all the code in English, because the libraries and language keywords are in English and it is thus more consistent.
This leads to business domain objects to be translated in English by the devs and they will make different or incorrect translations.
Then, all the stakeholders and requirements will be in French. All developers need to constantly map the real world names to the English names used in the code base, but that nobody else uses.
This leads to bugs, inconsistencies and extra cognitive load. It comes back to how hard "naming things" is.
Yes and it makes sense because great software eventually becomes worth internationalizing. If you start with a non-English code base and documentation, good luck translating that.
As a small anecdote, it took me maybe half a decade of casual programming to realize that “yield” is an actual English word, with an actual meaning, used in real conversations, and not just a weird “programming language keyword”.
I always assumed it was just a random keyword for a programming concept. Same for “thread” by the way (also took me a while to understand how to pronounce it as I only read it).
Fascinating, I had the same problem. Programming/CS became a lot more fun when I realized that the keywords and design patterns weren’t “just words” but were inspired by some “real world” phenomena.
A data point from my experience. My native language is Spanish, and in +15 years I have only at one job dealt with code in a language other than English (maybe I have been lucky).
I think as a developer one quickly realizes the value of sticking with the defaults (in this case English). Like configuring your system in English to be able to google the error messages; or Excel, which changes key shortcuts based on your language (ctrl+G for Guardar, to Save; ctrl+S in English); checking documentation in English or buying books in English because they are 2-3 years earlier than the local ones.
Using an US keyboard configuration also makes it much easier to type certain common characters in programming, although that might be too much to ask for :)
In my experience, the main difference is that people not comfortable with English will spend more time on naming things and code reviews.
But it tends to get better with experience.
Companies with a poor engineering culture often name things in their own language, which makes an awkward and confusing mix because everything else is in English.
I have noticed interesting regional differences too.
In France it is hard to get people to use English, but otherwise the grammar is mostly fine.
But in Asia it's easy to get people to use English, but it's not easy to get the grammar right. For example they have a hard time with plurals when naming variables.
Of course it's just my data point and a broad generalization, because there are also very skilled developers everywhere.
When you learn it straight in English it is easier. Even if you don't speak English!
You just associate the words with what they do, but it doesn't matter what it's written. You just associate in the same way the operators +, - work in math. It just happens.
I worked in Tokyo for Sony in the early 90's, when they were just getting into game consoles. Their C source files were "well documented" with code comments, but required an editor plugin to handle multiple possible character encodings for them, because this was before standards like Unicode and the Japanese language comments could be in one or more character encodings. That period was kind of haywire, because code could be copied from an email between people, but emails used other character encodings, causing a mishmash of possible comment encodings for any comment. And being a gaijin dev, I could not read the comments if they appeared correct anyway. Fun times.
