Citrine: Localized Programming Language

“it seems translation is a simple string replacement. I don’t think that’s enough to cover all languages.”

Honestly, simple string replacement isn’t good enough to cover any languages. Homonyms and synonyms, anyone? I suspect machine translation will be harder with code simply because there’s a lot less contextual information around individual words compared to ordinary prose with which to make a best guess as to meaning.

“I think AppleScript tried to do better, but can’t find examples”

Dr Cook’s HOPL paper on AppleScript gives an example of French and Japanese dialects (p20; can’t it paste here as it’s an image):

www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf

Not really the same thing as Citrine as it relied on manual localization of an application’s resources (custom keywords defined in AETE terminology, vs labels and tooltips on GUI controls). And, as you say, it did not do anything to localize user-defined words.

In any case, AppleScript is a really good example of how NOT to design an accessible language syntax. All the rigidity and tolerance of a machine language, with all the complexity and ambiguity of a natural one faked on top. (Plus all the fun that comes with arbitrary keyword injection—argh.)

This is why I say artificiality is good. Humans aren’t after Shakespeare, they’re after high-level understanding of program code.

“they felt it disorienting to express in their own native language programming constructs that they'd learned in English”

Trust me, going from natural-language English to programming-language English is just as discombobulating. (Been there, done that; made a deliberate point of remembering that experience.)

If you’re only testing it with existing programmers, you’re bound to skew your results because anything new and different to what they’re already used to is a disruption to their established flow. As in any scientific research, designing the right control for your trial is critical to avoiding GIGO.

A better test would be taking groups of English and non-English non-programmers, and teaching both of them entirely from scratch. (This assumes, of course, that each group’s teaching materials have been human-localized to the same standard, and all trainers follow the same script.) That way you avoid polluting your results with preconceptions and existing biases.

Out of interest, is there any more public information of your work here? iris-script[1], my own end-user-friendly language project and obvious anagram, has a way to go before I can begin to explore localizability, but it’s on the TODO list so I am collecting links to relevant material. Ta.

--

[1] https://github.com/hhas/iris-script

Hi, I am the creator of the language, my name is Gabor. You can ask questions if you like.

To answer some:

- Yes, we use machine translations, they serve as an example, they are far from perfect. Some language files are translated by native speakers. I think the website needs to be more clear about this.

- I use gendered language because coding is a men's job, women belong in the kitchen! ;-). No, just joking. Women are also welcome to become Citrine users. I just think the opening sentence is beautiful, it combines the concepts of male and female in a lovely, natural way ignoring today's PC-bullshit.

- No, Emoji-language is not allowed in the core. I only support natural languages. Endangered languages (EGIDS6 and higher) are also welcome. There is no limit.

I understand that there will be a lot of hate because of this language. I even received death threats over it. When a young developer I worked with brought up the idea I even laughed at him. However as I thought it over, the idea began to grow on me and I longed for a purely Dutch programming language (I had created one as a child for the C64 by just overriding the BASIC tokens). I figured that, if I longed for such a thing, maybe others do as well. I decided to share my code after some years just to give anyone interested some kind of basis or just discuss it.

It is important to realize that Citrine is trying to strike a balance. Programs will never read like a book. However, having a programming language using your own words and grammar just feels better and makes me more productive, I also tend to make fewer mistakes. The problem with just mixing Dutch with English programming languages is that is extremely ugly, also you never know when it's justified to use Dutch or English, especially when interacting with established English conventions, 3rd party software libraries or embedded languages in code (like shell or SQL). The other solution, translating everything into English is just horrible. I have encountered so many bugs that stemmed from miscommunication because of translation issues to English that I believe this will become a dead end eventually. One technique I am working on, that might help to improve the readability even further is simple macro processing, so you can say 'create a new Object' instead of 'Object new'.

Anyway, if you have any questions let me know, always happy to answer ;-)

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)`.

>I just think the opening sentence is beautiful, it combines the concepts of male and female in a lovely, natural way ignoring today's PC-bullshit.

Honestly, I am astonished that you can be so conscious of the effect of language on thinking in the context of programming, and yet so tone-deaf when writing your copy. This is not "today's PC bullshit", it is an effort to eradicate structural sexism going back at least half a century. It is not lovely and natural to use "man" as a default for "men and women" - it rings strangely to the modern ear, and you have attracted a number of comments about it. Maybe 40 years ago taking this position would have been forgivable, but in 2020 you are very much on the wrong side of this battle.

I commend this article by Douglas Hofstadter to you. It was written in 1982: http://leeclarke.com/courses/intro/readings/Hofstadter_Chang...