3 ms·

All keywords are in English. The standard library is in English. All external library APIs, open source or otherwise, are in English. But your own functions and

by adwn 8y ago

All keywords are in English. The standard library is in English. All external library APIs, open source or otherwise, are in English. But your own functions and variables have to be different? Why? If your grasp on English is sufficient for using a programming language, than it is also sufficient for using English identifiers. And I'm saying that as a native German speaker. > 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?

hsivonen 8y ago
It may make sense to use non-English words to name stuff that is about local legal concepts in enterprise software.
nemaar 8y ago
I very much agree with you. Having some strange words in the middle of a large code that is mostly english is just, well, weird. I think inconsistency is a serious issue.
gumby 8y ago
The language keywords are just keywords; you simply learn their meaning. As a native English speaker, though 'while' is a somewhat intuitively-named keyword, the 'for' keyword in c/c++ has to be learned. After a while you don't notice, any more than musicians have to learn Italian to play music (quick: what do 'fortissimo' and 'da capo ala fine' mean). 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.
- adwn 8y ago
  > I don't see any problem with source code that says something like 'auto maßtab = waage.m_maßtab();' There's no potential for confusion if you allow ASCII letters and 'ß'. Confusion can arise, however, when you allow all Unicode letters.
ken 8y ago
This isn't a very convincing argument to me. "We fail at source code localization in 4 other ways already" is not a good argument for "let's force a failure in a 5th way, too, even though that's the one place where there's no technical issue with it". 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) https://en.wikipedia.org/wiki/Subtext_(programming_language)
boudin 8y ago
If you work on a purely technical framework, yes it can make sense, even if i don't see why using french would be an issue for french people. Actually, i always liked the fact that since all the keywords are english, i can use mostly all the french language. When you work on a specialised field (for example some veterinarian software I worked in), learning the specific terms in your own language is already a lot. Learning how to translate those is adding much more complexity. It gets even worse when your specifications are written in one language (french in my example) and the software is written in another, so not re-using the syntax of the specifications. Add that most of the people will then have no understanding of what the code does without a list of translation, you end up in a quite messy situation... 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.

by adwn 8y ago

hsivonen 8y ago

It may make sense to use non-English words to name stuff that is about local legal concepts in enterprise software.

nemaar 8y ago

I very much agree with you. Having some strange words in the middle of a large code that is mostly english is just, well, weird. I think inconsistency is a serious issue.

gumby 8y ago

The language keywords are just keywords; you simply learn their meaning. As a native English speaker, though 'while' is a somewhat intuitively-named keyword, the 'for' keyword in c/c++ has to be learned. After a while you don't notice, any more than musicians have to learn Italian to play music (quick: what do 'fortissimo' and 'da capo ala fine' mean). 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.

adwn 8y ago
> I don't see any problem with source code that says something like 'auto maßtab = waage.m_maßtab();' There's no potential for confusion if you allow ASCII letters and 'ß'. Confusion can arise, however, when you allow all Unicode letters.

ken 8y ago

This isn't a very convincing argument to me. "We fail at source code localization in 4 other ways already" is not a good argument for "let's force a failure in a 5th way, too, even though that's the one place where there's no technical issue with it". 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) https://en.wikipedia.org/wiki/Subtext_(programming_language)

boudin 8y ago

If you work on a purely technical framework, yes it can make sense, even if i don't see why using french would be an issue for french people. Actually, i always liked the fact that since all the keywords are english, i can use mostly all the french language. When you work on a specialised field (for example some veterinarian software I worked in), learning the specific terms in your own language is already a lot. Learning how to translate those is adding much more complexity. It gets even worse when your specifications are written in one language (french in my example) and the software is written in another, so not re-using the syntax of the specifications. Add that most of the people will then have no understanding of what the code does without a list of translation, you end up in a quite messy situation... 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.