Sometimes I'm tempted to use Russian identifiers for application domain terminology, because very often there's no adequate translation or I just don't know English enough to translate some terms. I like the following example: every man here has name combined from last name (Фамилия) which is used for all family members, first name (Имя), that's pretty standard. But there's also third name: Отчество, which is basically father's name with some suffix, e.g. father Иван will have child with third name Иванович. Now I've seen all kinds of translations for those terms, including plain wrong. Last name, family name for Фамилия, first name, name for имя, father name, second name, patronymic, patronymic name for отчество. I've seen bugs because one developer interpreted those terms differently from another.
And that's just for name. There are plenty of other terms. Add to that that many developers are bad at English and at best will use first result from Google Translate. So may be national identifiers have its place.
Sounds like you get to skirt a few of the problems outlines in Falsehoods Programmers Believe About Names[1]. That's nice for programmers in Russia that deal with Russia only, if true. :)
1: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
Of course the whole point of the article you mentioned is that making such assumptions leads to odd behavior. I (an American) lived in Russia for a while. One time I was having a couch delivered to my apartment and had to give the store my full name. I was delighted to see my middle name show up on the receipt in the отчество (patronymic) field with the Russian patronymic suffix ович attached. I still got the couch no problem, but I got a laugh out of their attempt to shoehorn my (clearly not Russian) names into their naming paradigm.
> it made the code much more readable
"Much more readable"? It made the code base inconsistent with the rest of the language. Are you saying that they were lacking even basic English language skills?
I don't see any problem with source code that says something like 'auto maßtab = waage.m_maßtab();' 'auto' and '=' are simply language tokens.
There's no potential for confusion if you allow ASCII letters and 'ß'. Confusion can arise, however, when you allow all Unicode letters.
To me, using English keywords everywhere is a historical accident, not a design goal. In next-generation systems like Subtext [1], it looks entirely possible to add localization to source code, too.
Once you throw out the Lisp way of having one namespace for all symbols (or, OK, like 7 in CL), to be used as functions or values, and go to a system where you want to be able to statically type-check everything, why not fully commit to it and let users give local names to identifiers? Then we won't be limited to legacy C-style naming rules, or have to argue about how many space characters to add to make all their names line up on a high-resolution VT100 emulator, either.
[1]: https://en.wikipedia.org/wiki/Subtext_(programming_language)
Yes i'm saying that a lot of colleagues were lacking basic english skills, and i don't see the issue with that. English is a nice to have to communicate with people abroad, but absolutely not necessary to live in France.
Oddly (to me, anyway), the software house that made the program was located in Africa.
When I was in france, all the software were written using french identifiers. It was much better this way since none of the code was meant to be shared outside of france and it made the code much more readable for people who were supposed to work on it. Why should it be possible only for latin based languages?