4 ms·

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

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.

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.