Non-English-based programming languages | Hacker News Reader

Non-English-based programming languages

en.wikipedia.org

57 pointsshocks18 comments

There is a Chinese programming language [1] (better archive of the original [4]) based off the phrase 草泥马 (cǎonímǎ) meaning grass mud horse [2]. It's a meme in China because it's a homonym for 肏你妈 (càonǐmā) meaning "fuck your mother". Foreign internet culture is cool [3].

1. https://code.google.com/archive/p/grass-mud-horse/

2. https://en.wikipedia.org/wiki/Grass_Mud_Horse

3. https://en.wikipedia.org/wiki/List_of_Internet_phenomena_in_...

4. http://zqcoder.qiniucdn.com/data/20120914162548/index.html

A recent victim of an over leveraged and under regulated commodities exchange here in Yunnan who lost vast amounts of money decided to parade an alpaca about the city in protest, describing it with this same phrase.

Interestingly, as a native Spanish speaker, when I was a newbie, I found that the programming languages being in English being an advantage. When reading a programming book in Spanish, it was clear what was a keyword or standard library function (English), and what was code written by the book writer (Spanish). When I first read a programming book in English, I was sometimes confused trying to figure whether a function call was calling something that was provided by the language or something that was defined elsewhere in the book. I wonder, though, if this confusion was because I was so used to read books in Spanish, or if native English learners also experience this sometimes.

Look at the typical domain of programming: procedures, branching, merging, data structures, time, parallelism. We already have a burgeoning set of visual standards (eg. look at those recent console git hack fonts with symbols for merge, branch, etc.)... it wouldn't take too much effort to replace the majority of control structure identifiers in most languages with intelligent language-neutral graphics, and it would simplify the hassle of syntax when considering programs written in languages with which you are not personally familiar. Some nerdy lisper should implement this, bonus if it can eat code and libraries in arbitrary languages.

So you want to reinvent APL?

APL examples seem to suffer from the perl problem: people squash stupendous amounts of code in to single lines rendering them all but unreadable to newcomers.

Perhaps a revised APL with more modern/simplified symbols and some syntactic rules reducing the scope for jumbled muck, and an IDE that translates the symbols in to native human language explanations on mouseover.

Given the prevalence of subject-object-verb order in non-English languages, I'm mildly surprised there aren't more RPN or Forth-like languages in this list.

People just don't like RPN for some reason (habit maybe?). It's a mathematical preference, with little apparent feedback from the spoken language.

But I don't see the prevalence of subject-object-verb. At least western languages are mostly subject-verb-object. Are you talking about eastern ones?

SOV languages are the most numerous at 45% incidence[0], and include some big western ones, like Latin.

[0] https://en.wikipedia.org/wiki/Subject%E2%80%93object%E2%80%9...

Latin is not really SOV. It is common, but word order can vary greatly. In this case, you can actually use any combination (SOV, SVO, OVS...). Classical writers would often place the most important or impactful word in a sentence last, and this word is often the verb.

I think RPN works okay in natural language because you can often use discourse- and world-knowledge to guess the verb before hearing it. When reading programming languages that may work less well. But also note that, at least in some languages, there seems to be some pressure to move the verb to the front. For example, German is classified as a verb-final language but in main clauses the verb is actually "moved" to second position (subject-verb-object). Final position is only "preserved" in subordinate clauses. This suggests that early verbs may be easier to process.

I'm always surprised that Ruby in particular, given its purely Japanese roots, resembles SVO a lot more than SOV.

Though, on the other hand, for object-oriented languages in general, I often wish people new to them knew Japanese, because the "." operator (field-access, method lookup/calling) is kind of hard to explain in terms of English grammar, but in Japanese, you can just tell students to pronounce it as a の and they immediately get it.

I suspect the influence of Smalltalk and Perl on Ruby kept it from being more SOV-ish. Too bad, since I actually have an odd preference for SOV and OSV grammars. They're easier on my brain.

I think "backwards of" gets the point across alright for an English version of "."/no.

> Ruby ... resembles SVO a lot more than SOV

What parts exactly? As a Japanese speaker, all the object methods seem super intuitive. Specifically, the iterator methods vs traditional for loops.

Rails and what not, however, not so much.

One of those is Perl - in Klingon! https://metacpan.org/pod/Lingua::tlhInganHol::yIghun

I first noticed this issue when I saw a guy struggling with an English-Portuguese dictionary to try to understand the error messages that the university's Burroughs B6700 Fortran compiler had added to his program listing. Soon after that I saw another guy having a really hard time learning Basic because he couldn't memorize "N E X T", a sequence of letters which meant absolutely nothing to him. I had previously thought that with Fortran, Basic and Algol having so few keywords this wouldn't be a problem like it would be for Forth or Smalltalk.

I once saw a computer which had a Basic with keywords in Portuguese, but I have never found any references to it on the Internet. Logo was translated by several people, but unfortunately they didn't coordinate their efforts so Portuguese Logo programs were even less portable between versions than normal.

In 1984 I translated all of Smalltalk as described in the "blue book" to Portuguese, but it wasn't easy:

1) "self" does not have a nice equivalent

2) lots of words like "copy" can be either a verb or an adjective. No matter which Portuguese option you choose it will work in some contexts and be really bad in others

3) lots of words like "new" are gender neutral. No matter which Portuguese option you choose it will work in some contexts and be really bad in others

4) word order for adjectives is the opposite in English and Portuguese. This actually fits in well with the postfix syntax of Smalltalk's unary selectors, but breaks down when naming components: "car door window" works but it would have to be "janela da porta do carro", which doesn't work

5) You might be able to tell the difference between "ordered" and "sorted" when describing collections, but Portuguese uses the same word for both

Smalltalk-80 makes a distinction between String objects and Symbols. So you can have many 'new' strings but that gets converted into a systemwide unique #new symbol which is used for method names and other things. I created a MultiSymbol class in Smalltalk-V that would convert any of a set of strings into the same symbol. When going the other way around (to print, for example), it would use the value of a global variable to pick between the objects. So you could type in your program in Russian and ask it to be listed in Portuguese, for example. This was good enough for all the standard symbols, but you would have to add translations for any new symbol you created yourself. It got the job done, but by the late 1990s everyone I met had a strong opinion that programming languages have to be in English.

Two funny stories about Portuguese and programming language books:

1) my father once brought home from work a book about programming with dBase-II. The problem was that they had not only translated all of the text but the program listings as well. I told him that if he tried typing in any of the examples it would not work at all. I wonder if anybody ever bothered trying it.

2) A company called Brascom was selling illegally imported Cromenco computers in Brazil with the name BR-1000. They decided to rename the Cromix operating system to BR-1000 as well. In the manual they simply replaced every instance of "cromix" with "br1000". A student complained that he couldn't get one of the examples in the manual to work, so I looked at it and noticed it had a "br1000(300);" system call in it, so I suggested that he try "cromix(300);" instead. It now compiled and ran just fine.

Ha! Very interesting. Thanks for sharing.

Reply on news.ycombinator.com