3 ms·

I've said too much about this subject in the past [1], but my litmus test for "localized" programming languages is a Korean support (both because I speak it nat

I've said too much about this subject in the past [1], but my litmus test for "localized" programming languages is a Korean support (both because I speak it natively and because it is very much different from most Indo-European languages). It spectacularly fails. At the very least it is evident that Citrine only ever cares about languages with prepositions (e.g. `x on: 'greet:' do: { ... }`). [1] https://news.ycombinator.com/item?id=21352775 https://news.ycombinator.com/item?id=21352775

jka 6y ago
There's little reason, I suppose, why internationalizing the code of a software program is any less challenging than internationalizing an application. That is to say: language keywords, function and variable names, comments, documentation, and perhaps even multi-token structures might all require associated translation strings. And as with translating an application (or any text, really), the source material might be written in one native language, and only later be translated into others based on demand and interest. Software projects have the interesting property that partial translations might make sense under some circumstances. A commonly-used API function could be translated first, for example. It'd be impressive to work on a project where multiple developers are each individually contributing to literally the same codebase, but each reading and writing it in their own native language(s). (clearly a situation like that would require a lot of input from translators too - ideally with context for the software language and the project itself)
qayxc 6y ago
You don't have to go as far as Korean - that BS fails H A R D even with other Germanic languages. It's like whoever did the translations just took the English version and chose the first entry in the dictionary without even a second thought. The translations are definitely machine translations and not done by native speakers. This results in hilarious constructs that are hard to decipher even when knowing the context. As soon as I saw inconsistent grammar and even simple words being completely mistranslated, I dismissed the whole thing.
hhas01 6y ago
“Citrine only ever cares about languages with prepositions” You’re confusing keyword/identifier localization for natural language. I agree with everyone who says NL is the wrong problem to solve, but that’s not what Citrine is attempting to do. Look at it this way: Citrine code is NOT natural English either. At most, it is a sort of “pidgin English” where individual words can be readily understood but the grammar is wholly artificial. For instance, a Chinese or Japanese dialect should continue to use whitespace to separate identifiers. It’s a programming language, not a natural one, and that difference is the point. Trying to “fake it” leads to dead-end mistakes like AppleScript. Trying to do it for real creates exactly the sort of ambiguities and imprecision that a programming language is meant to eliminate. It’s about finding the right compromise between human accessibility and machine precision, and anything that breaks down barriers between the traditional US English-dominated programming world and the billions of humans who speak something else has got to be a step in the right direction.
- lifthrasiir 6y ago
  I definitely agree that localized languages can only reflect a subset of human languages (and it's of course true even for English-based languages), but that doesn't make my point moot. If the author did really care about other languages and wanted to pursue the fixed syntax, every identifier should have been strictly nouns or verbs and nothing else; for example (say) `animate(source: X, target: Y)` instead of `animate(from: X, to: Y)`.
  - hhas01 6y ago
    “every identifier should have been strictly nouns or verbs and nothing else” Totally agree. TBH I don’t think the authors’ enthusiasm, while admirable, is quite matched by their knowledge and experience. A bit more up-front learning could probably save them disappearing down some obviously wrong paths. As you say, they should focus on verbs and nouns, and getting those to machine-translate precisely. Nailing that would be a big deal just in itself. If they later want to experiment with adding prepositions to make code read “more naturally”, make the system add those on a per-language basis according to per-language rules laid down by native-language speakers. Thus in English the method signature might present as `animate(from: source, to: target)`, because that’s what English readers expect and like. But that doesn’t mean that `from` and `to` should be translated to every other language, because that’s just an exercise in cutesy-clever nonsense, burying what is significant under what is not, and software already suffers from more than enough of that.
rurban 6y ago
Korean is special because it still has the one remaining unicode bug in the spec, U+ffa0 HALFWIDTH HANGUL FILLER is still a valid identifier. http://perl11.org/blog/unicode-identifiers.html http://perl11.org/blog/unicode-identifiers.html Almost nobody got that right.

jka 6y ago

There's little reason, I suppose, why internationalizing the code of a software program is any less challenging than internationalizing an application. That is to say: language keywords, function and variable names, comments, documentation, and perhaps even multi-token structures might all require associated translation strings. And as with translating an application (or any text, really), the source material might be written in one native language, and only later be translated into others based on demand and interest. Software projects have the interesting property that partial translations might make sense under some circumstances. A commonly-used API function could be translated first, for example. It'd be impressive to work on a project where multiple developers are each individually contributing to literally the same codebase, but each reading and writing it in their own native language(s). (clearly a situation like that would require a lot of input from translators too - ideally with context for the software language and the project itself)

qayxc 6y ago

You don't have to go as far as Korean - that BS fails H A R D even with other Germanic languages. It's like whoever did the translations just took the English version and chose the first entry in the dictionary without even a second thought. The translations are definitely machine translations and not done by native speakers. This results in hilarious constructs that are hard to decipher even when knowing the context. As soon as I saw inconsistent grammar and even simple words being completely mistranslated, I dismissed the whole thing.

hhas01 6y ago

“Citrine only ever cares about languages with prepositions” You’re confusing keyword/identifier localization for natural language. I agree with everyone who says NL is the wrong problem to solve, but that’s not what Citrine is attempting to do. Look at it this way: Citrine code is NOT natural English either. At most, it is a sort of “pidgin English” where individual words can be readily understood but the grammar is wholly artificial. For instance, a Chinese or Japanese dialect should continue to use whitespace to separate identifiers. It’s a programming language, not a natural one, and that difference is the point. Trying to “fake it” leads to dead-end mistakes like AppleScript. Trying to do it for real creates exactly the sort of ambiguities and imprecision that a programming language is meant to eliminate. It’s about finding the right compromise between human accessibility and machine precision, and anything that breaks down barriers between the traditional US English-dominated programming world and the billions of humans who speak something else has got to be a step in the right direction.

lifthrasiir 6y ago
I definitely agree that localized languages can only reflect a subset of human languages (and it's of course true even for English-based languages), but that doesn't make my point moot. If the author did really care about other languages and wanted to pursue the fixed syntax, every identifier should have been strictly nouns or verbs and nothing else; for example (say) `animate(source: X, target: Y)` instead of `animate(from: X, to: Y)`.
- hhas01 6y ago
  “every identifier should have been strictly nouns or verbs and nothing else” Totally agree. TBH I don’t think the authors’ enthusiasm, while admirable, is quite matched by their knowledge and experience. A bit more up-front learning could probably save them disappearing down some obviously wrong paths. As you say, they should focus on verbs and nouns, and getting those to machine-translate precisely. Nailing that would be a big deal just in itself. If they later want to experiment with adding prepositions to make code read “more naturally”, make the system add those on a per-language basis according to per-language rules laid down by native-language speakers. Thus in English the method signature might present as `animate(from: source, to: target)`, because that’s what English readers expect and like. But that doesn’t mean that `from` and `to` should be translated to every other language, because that’s just an exercise in cutesy-clever nonsense, burying what is significant under what is not, and software already suffers from more than enough of that.

rurban 6y ago

Korean is special because it still has the one remaining unicode bug in the spec, U+ffa0 HALFWIDTH HANGUL FILLER is still a valid identifier. http://perl11.org/blog/unicode-identifiers.html http://perl11.org/blog/unicode-identifiers.html Almost nobody got that right.