from FrenchXpCommunity:
Q: Can I ask what it's like programming when your spoken language is not English: does the fact that the computer language has English syntax (are there any that don't?) impair the process or require you to have a basic understanding of English? I'd imagine the variables you create would be in your own language, introducing a mix. If you work for an international company (that is, American) do they make you use English variables too? Just curious. Merci!
In my experience, and according to some colleagues who do not speak English, the foreign programming background language was in fact helpful while learning programming. It provides an immediate and handy distinction between keywords, built-in functions, and the domain-related identifiers.
Also, you don't stay too long in the naive confusion between computer languages and natural language. (By the way, compilers use English keywords but not English syntax).
Personally, I think I wouldn't have given more than three weeks to programming if the languages had French keywords. I don't know why. Many years ago I read about LSE, a French-keyword Basic. I found it ugly. French equivalent for while and until are tant que and jusqu'a ce que, respectively. You notice the need for underscores in the many programming languages where space separates semantic items.
Now, I think I don't feel any difference or difficulty. I don't relate it to being somewhat at ease with written English. It's just invisible, like a kind of syntactic canvas underneath the intentions you get while reading the program.
I worked in a big (not so) international company where a methodologist had decreed the use of English in all VB programs, applying not only to identifiers but also to comments. This produced the stupidest and most illegible programs I've read in my career. Given the domain (payroll and billing) and the completely ad hoc approach, it was fortunately very easy to convince our manager that the probability of someone in a foreign agency reading our programs (not to mention trying to use them) was not worth the cost it took to write them in English.
The programming language itself is like learning a foreign language, any foreign language. The few English words among the many symbols and expressions to learn don't matter that much.
It's on a higher level that the real problems begin. We usually keep everything in the source in English. The names of classes make their way into the conversational language. When talking about the system to non-technical users we have to keep remembering to translate all the terms into our native language. Our own jargon consists of an awkward pidgin mix of languages. The comments in the code are often short statements, in a limited subset of English, since it's slower to write in a language other than your native.
All these things add friction. Not much, but it's probably measurable.
As a non-native speaker of English, I have some difficulties in programming.
My difficulties usually lie in choosing variable/function names, especially among the synonyms. We don't use an alphabet in my native language (I am Korean) and, it would be ugly and usually more confusing if we try to use alphabetized Korean forcibly. So, I often refer to a synonym dictionary when programming, but even when I refer to it, I sometimes get lost in choosing the most appropriate word.
Another difficulty would be working with other programmers who are not good at English (usually less fluent than me). I'm very confused at their choice of words and non-guessable abbreviation for variable names, and I must go to them and ask the meanings, which slows the process.
We're expecting an English-native programmer in my company next month, and I'm curious what he'll say after reading our source code, and in what way he'll affect us.
-- JiwonSeo
Slight tangent....
I'm very confused at their choice of words and non-guessable abbreviation for variable names...
Even as a native English speaker, I can sympathize with you. Average programmers don't think much about the names they choose, and so their names don't often make good sense. Naming is hard, and extremely important. Abbreviations are never appropriate unless they come from a short, agreed-upon list that programmers new to the team may consult. Ad hoc abbreviation is sloppy. Just be glad you don't work in telecommunications, where people use acronyms for everything to project an impression of knowledge.
I worked with some German colleagues for a while, and noticed a tendency to re-invent library functions.
I got the impression that when searching API documentation they were likely to stop when they found something close -- and not notice the method a few lines below that already did exactly what they wanted.
When I started programming, I did not know English. Keywords named concepts and I just had to learn them. When I started to use libraries, I started to learn English. Ten years later, English is my first language for reading, I write 98% of my code in English, but keywords still are not English. Direct translation just doesn't make much sense. -- GirtsKalnins
LSE is Language Symbolique d'Enseignment (symbolic language for teaching). It was created in 1970 and was used through the early 1980's. The previous guy who mentioned LSE had the loop construct wrong. The equivalent of the 'for' loop is the 'pour'; not so bad. Anyway, the whole saga is documented (in French) at http://wwwsi.supelec.fr/yn/sagaLSx.html
Apparently, LSE was the successor to LSD (Language Symbolique Didactique). It actually had some remarkable features for its time.
First Rule of ProgrammingWhenNotSpeakingEnglish: Don't.
--YuriKhan?
That's an issue that really comes up frequently here, in Israel.
Most native Israelites have quite decent English, especially coders, Hebrew being a 'small' language, thus not having any decent technical publications. I noticed that when coding with other native Israelites, we often switch to a sort of PseudoEnglish? or a local dialect of the InternationalHackerLanguage? to a certain degree.
I personally find it confusing sometimes, switching languages back and forth. The degree of English usage varies with different individuals. Mostly, the sentences are made up of Hebrew auxiliary verbs and prepositions, with English verbs and nouns. (Example: "ta'ase Sort laArray" - "sort the array" - literally: "do a Sort to the Array") Variable, function, and object names are given only in English, maybe with the exception of humour.
An exception to that is when coding with Russians, which is also common in Israel, who often pronounce English words as written, which makes it difficult to understand (for example, pronouncing the e in called and marked). Finding Russian variable names is not uncommon, and especially error-messages in Russian. So actually if PairProgramming with them, I find myself using much more conventional Hebrew.
I remember reading something (I think it might have been in a DouglasHofstadter book) where the author asked a non-English-speaking programmer what it was like programming with keywords and so forth in a language he didn't speak. The guy said he probably thought about it in the same way as English-speaking musicians think about all the Italian "keywords" in musical notation... they're just opaque symbols you memorize and then don't think about.
Good point. Even after learning another Romance language, I often overlook the fact that the words on a musical score have a non-technical meaning.
I suppose this could be listed as an advantage to Lisp's car & cdr functions: They're foreign to everybody. (^_^) It could be interesting to create a programming language in which all the keywords are intentionally not human language words. -- RobertFisher
I guess you'd call that a ConLang ProgrammingLanguage (ConLangProgrammingLanguage??).
I learned Basic as a child before any meaningful exposure to English, and I memorized the keywords as one would meaningless magical incantations, their pronunciations in my mind's ear being whatever seemed appropriate middle ground between my mother tongue and generic foreign gibberish of the sort I heard in movies. It worked pretty well. I imagine it would be much harder when getting to know a large library that tries to ease the learning curve by using very predictable meaningful names. Nowadays I notice people with poor English sometimes have trouble giving useful (or even sensible) names to things. This tends to be a serious problem precisely when the thing they're programming is most ingenious and useful.