5 ms·

This stops most of the world naming things in their native language.

by ZiiS 8y ago

kungtotte 8y ago
Speaking as someone who doesn't have English as their first language I think programming should be in English and ASCII. This includes identifiers and filenames. Strings on the other hand should be 100% valid Unicode, never ASCII. This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world.
- lifthrasiir 8y ago
  > This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world. Uh, no? You are not supposed to be able to read this valid Unicode string literal in Korean: `"그뤼고 이 문좌열은 일부려 기ㅖ버역을 어럽게하러고 오타비문이 산개해 있구먼요."` Also a significant portion (and possibly the majority) of codes would be ever read and written by a small group of people, often sharing a common language other than English, so non-English code is just fine for them. If you are saying that a public library should be written in English, I almost agree---there would be some exceptions though.
  - yarosv 8y ago
    Do you mean you want like C#? public class 그뤼고 { private 이 이 {get;set;} public 그뤼고() { var 문좌열은 = 이.문좌열은; var 기ㅖ버역을 = Enumerable.Range(0, 10); var 오타비문이 = 기ㅖ버역을.Select(요 => 요); } } public class 이 { public int 문좌열은 {get;set;} }
    - lifthrasiir 8y ago
      Sometimes, though my example was intentionally obscured to prevent machine translation and you were not aware of Korean conjugations (usually omitted in identifiers) ;-) I have seen numerous instances of pseudo-English when it comes to naming. It is hard to name things in non-native tongues. When reasonable, reducing that overhead can be indeed beneficial.
      - yarosv 8y ago
        Oops (yes, I don't know what it meant). I mean I speak Ukrainian and Russian. If I saw the code like that in my native tongue, I would be upset. Plus it is pain to alt+shift between languages all the time.
- ptx 8y ago
  Since keywords and APIs are usually in English, continuing to follow that convention in your variable names is often the most natural option. But in cases where the program will be dealing with some concept that doesn't exist in English, being able to refer to things by their actual name, in the native language (assuming that's also the native language of the customer and development team), is much better than inventing a confusing and unnatural English translation.
coldtea 8y ago
That's the main benefit. A programming language's identifiers is not the place to express one's national identity. They should be utilitarian, and easily understood by programmers across countries. Since you're already supposed to understand the syntax of every major programming language (which is based on english) you can make do with english keywords too. Nothing worse than opening some code to find bizarro foreign language identifiers. (And I'm no native english speaker, so I'm not speaking as someone who's ok with this because english is their language or ASCII fits their default keyboard layout: it just makes sense).
- scrollaway 8y ago
  I see what you're saying, but then again, this is exactly how many chinese programmers feel all the time. > Nothing worse than opening some code to find bizarro foreign language identifiers.
  - lultimouomo 8y ago
    So we should live in a world where Chinese programmers share knowledge only with Chinese programmes, Americans share among them and with Brits, Aussies and Canadians, and Mexicans share with Spaniards? I'm not a native English speaker, and I have only to loose in this scenario.
    - detaro 8y ago
      There are languages that allow more than ASCII, and that's not what happens in them.
      - yorwba 8y ago
        For that matter, there are human languages besides English that can be written using only ASCII (sometimes by transliterating) and that's not what happens in them. Just like people know they have to write in English on HN to communicate, they also write their code in English when they plan to open-source it and share with the rest of the world. As for closed-source projects ... if your company doesn't conduct its business in English, why force the code to be in English? The only people whom that'd benefit are never going to see it.
ckastner 8y ago
As a non-native English speaker, I understand the desire to name things in my native language (German), but for all but languae francae, naming things in a native language presents an obstacle to sharing these things with others. Compare итератор and 迭代器, which are complete mysteries to me produced by Google Translate. If my intention were to reach as many people as possible, I'd use "iterator" (which, coincidentally, works for English and my native German).
- johannes1234321 8y ago
  There are technical terms and there is domain terminology. If once worked in finance and there is a difference between GAAP accounting and German accounting rules. If my algorithms used English terminology to be consistent with technical terms this would be confusing inneach review. Using German terms (even combined with English "get" or "set", like "getBetriebsertrag") there was beneficial, even though it always confussed new members of the team.
- beaconstudios 8y ago
  funnily enough, the Russian also spells "iterator", just in Cyrillic. But your point stands nonetheless.
zozbot123 8y ago
This is something that only humans care about, not computers. And humans can be accommodated by prettyprinting - or, in a pinch, by roundtrip conversion from an ASCII-only format to a "rich", Unicode-based one, and back. But let computers have their simple, ASCII-based identifier names. E.g. https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode is a thing, and is routinely used for "native-language" domain names. But guess what, these domain names are still ASCII under the hood! (Indeed, we should arguably move away from the notion of a single character string as the only human-facing semantics that an identifier is associated with-- there should be a higher layer, perhaps with multiple choices of e.g. native language, formatting and the like. Human facing semantics are closer to "literate" documentation than to anything that compilers should have to deal with. Yes, the "native", underlying representation should still be something that we can somehow make sense of - I'm not saying that our identifiers should be GUIDs or anything like that! But it will only be resorted to in a pinch.)

This stops most of the world naming things in their native language.

by ZiiS 8y ago

This stops most of the world naming things in their native language.

Speaking as someone who doesn't have English as their first language I think programming should be in English and ASCII. This includes identifiers and filenames. Strings on the other hand should be 100% valid Unicode, never ASCII. This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world.

lifthrasiir 8y ago
> This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world. Uh, no? You are not supposed to be able to read this valid Unicode string literal in Korean: `"그뤼고 이 문좌열은 일부려 기ㅖ버역을 어럽게하러고 오타비문이 산개해 있구먼요."` Also a significant portion (and possibly the majority) of codes would be ever read and written by a small group of people, often sharing a common language other than English, so non-English code is just fine for them. If you are saying that a public library should be written in English, I almost agree---there would be some exceptions though.
- yarosv 8y ago
  Do you mean you want like C#? public class 그뤼고 { private 이 이 {get;set;} public 그뤼고() { var 문좌열은 = 이.문좌열은; var 기ㅖ버역을 = Enumerable.Range(0, 10); var 오타비문이 = 기ㅖ버역을.Select(요 => 요); } } public class 이 { public int 문좌열은 {get;set;} }
  - lifthrasiir 8y ago
    Sometimes, though my example was intentionally obscured to prevent machine translation and you were not aware of Korean conjugations (usually omitted in identifiers) ;-) I have seen numerous instances of pseudo-English when it comes to naming. It is hard to name things in non-native tongues. When reasonable, reducing that overhead can be indeed beneficial.
    - yarosv 8y ago
      Oops (yes, I don't know what it meant). I mean I speak Ukrainian and Russian. If I saw the code like that in my native tongue, I would be upset. Plus it is pain to alt+shift between languages all the time.
ptx 8y ago
Since keywords and APIs are usually in English, continuing to follow that convention in your variable names is often the most natural option. But in cases where the program will be dealing with some concept that doesn't exist in English, being able to refer to things by their actual name, in the native language (assuming that's also the native language of the customer and development team), is much better than inventing a confusing and unnatural English translation.

coldtea 8y ago

That's the main benefit. A programming language's identifiers is not the place to express one's national identity. They should be utilitarian, and easily understood by programmers across countries. Since you're already supposed to understand the syntax of every major programming language (which is based on english) you can make do with english keywords too. Nothing worse than opening some code to find bizarro foreign language identifiers. (And I'm no native english speaker, so I'm not speaking as someone who's ok with this because english is their language or ASCII fits their default keyboard layout: it just makes sense).

scrollaway 8y ago
I see what you're saying, but then again, this is exactly how many chinese programmers feel all the time. > Nothing worse than opening some code to find bizarro foreign language identifiers.
- lultimouomo 8y ago
  So we should live in a world where Chinese programmers share knowledge only with Chinese programmes, Americans share among them and with Brits, Aussies and Canadians, and Mexicans share with Spaniards? I'm not a native English speaker, and I have only to loose in this scenario.
  - detaro 8y ago
    There are languages that allow more than ASCII, and that's not what happens in them.
    - yorwba 8y ago
      For that matter, there are human languages besides English that can be written using only ASCII (sometimes by transliterating) and that's not what happens in them. Just like people know they have to write in English on HN to communicate, they also write their code in English when they plan to open-source it and share with the rest of the world. As for closed-source projects ... if your company doesn't conduct its business in English, why force the code to be in English? The only people whom that'd benefit are never going to see it.

ckastner 8y ago

As a non-native English speaker, I understand the desire to name things in my native language (German), but for all but languae francae, naming things in a native language presents an obstacle to sharing these things with others. Compare итератор and 迭代器, which are complete mysteries to me produced by Google Translate. If my intention were to reach as many people as possible, I'd use "iterator" (which, coincidentally, works for English and my native German).

johannes1234321 8y ago
There are technical terms and there is domain terminology. If once worked in finance and there is a difference between GAAP accounting and German accounting rules. If my algorithms used English terminology to be consistent with technical terms this would be confusing inneach review. Using German terms (even combined with English "get" or "set", like "getBetriebsertrag") there was beneficial, even though it always confussed new members of the team.
beaconstudios 8y ago
funnily enough, the Russian also spells "iterator", just in Cyrillic. But your point stands nonetheless.

zozbot123 8y ago

This is something that only humans care about, not computers. And humans can be accommodated by prettyprinting - or, in a pinch, by roundtrip conversion from an ASCII-only format to a "rich", Unicode-based one, and back. But let computers have their simple, ASCII-based identifier names. E.g. https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode is a thing, and is routinely used for "native-language" domain names. But guess what, these domain names are still ASCII under the hood! (Indeed, we should arguably move away from the notion of a single character string as the only human-facing semantics that an identifier is associated with-- there should be a higher layer, perhaps with multiple choices of e.g. native language, formatting and the like. Human facing semantics are closer to "literate" documentation than to anything that compilers should have to deal with. Yes, the "native", underlying representation should still be something that we can somehow make sense of - I'm not saying that our identifiers should be GUIDs or anything like that! But it will only be resorted to in a pinch.)