this post was submitted on 19 Nov 2023
42 points (81.8% liked)
Programming
17418 readers
238 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Sweet, we need more non-English programming languages. I'm surprised that existing programming languages haven't been translated yet.
There are a fair number of them: https://en.m.wikipedia.org/wiki/Non-English-based_programming_languages
But arguably, as long as the compiler supports unicode, it shouldn't matter that much what language the keywords are in. There are other more important issues impacting how easy it is to program in non-English languages:
Another problem is that the grammars of many well-supported programming languages also mirror English/Romance language grammars. Unfortunately, dealing with that is more than just a matter of swapping out keywords.
EDIT: I may have been unclear; I wasn't trying to imply that this problem is greater than or even equal to the lack of documentation, tutorials, libraries, etc. Just that it's another issue, aside from the individual words themselves, which is often overlooked by monolingual people.
What do you mean by that?
I'm no linguist, but I have some Japanese language ability, and Japanese seems to be pretty different, grammatically, from English, so I'll draw on it for examples. I also had a quick look at some Japanese-centric programming languages created by native speakers and found that they were even more different than I'd imagined.
Here's a first example, from an actual language, "Nadeshiko". In pseudo-code, many of us would be used a statement like the following:
Here's a similar statement in Nadeshiko, taken from an official tutorial:
A naive translation of the individual words (taking some liberties with English) might be:
I know, I know, "displayment" isn't a real English word, but I wanted to make it clear that the function call here isn't even dressed up as a verb, but a noun (of a type which is often used in verb phrases... it's all very different from English, which is my point). And with a more English-like word order, it would actually be:
Here's another code sample from the same tutorial:
And another naive translation:
And finally, in a more English-like grammar:
And here's a for...in loop, this time from my own imagination:
Becomes:
Naively:
More English-y:
You may have noticed that in all of these examples, the "Japanese" code has little whitespace. Natural written Japanese language doesn't use spaces, and it makes sense that a coding grammar devised by native speakers wouldn't need any either.
Now, do these differences affect the computer's ability to compile/interpret and run the code? No, not at all. Is the imposition of English-like grammar onto popular programming languages an insurmountable barrier to entry for people who aren't native English speakers? Obviously not, as plenty of people around the world already use these languages. But I think that it's an interesting point, worth considering, in a community where people engage in holy wars over the superiority or inferiority of various programming languages which have more in common than many widely-spoken natural languages.
I'm trying to think of examples of this, and I actually don't know that this is true. Here are the examples I can think of:
.method()
syntax is similar to "subject-verb" order, but we also havefunction(self, ...)
which is the reverse of that.for foo in bar
is used in a few languages (or sometimesforeach
). But many languages use a totally non-English construct, such asfor i = 0; i < limit; i++
orfor (auto foo : bar)
.What else is there?
Drawing on Japanese, which is the only non-English language I have significant experience with,
object.method(parameter)
would feel more natural asobject.(parameter)method
, possibly even replacing the period separator with a Japanese grammatical construct (with no equivalent in English) that really suits this use case. Even the alternativefunction(self, parameter, ...)
would mesh better with natural Japanese grammar as(self、parameter、〜)function
. The majority of human languages have sentences which run Subject-Verb-Object, but a handful which includes Japanese run in the order Subject-Object-Verb.I gave an example of an alternative
for...in
loop in another comment here, so I won't rehash it here. But following the general flow of Japanese grammar, thatfor
at the beginning of the statement would feel much more natural as aで
(or "with
") at the end of the statement, since particles (somewhat similar to prepositions in English) go after the noun that they indicate, rather than before. And since semicolons don't exist in Japanese either, even they might be replaced with a particle like "と
".There aren't any big problems here, but a plethora of little things that can slowly add up.
Object wa parameter o method desu
I'm not disagreeing outright but... Why do we need more non English programming languages? Is there a specific practical reason?
The only language translation I'd maybe consider to accept in programming is Esperanto. Anything else just sounds like a terrible idea.
Why esperanto?
It's a neutral, easily accessible language. Having it in programming could incentivize more people to learn it as well.
The main issue is programming in a specific language limit who can contribute to those who speaks that language. In that sense English makes sense as it is already a widely used language in a work context. It would probably limit those who are willing to use the software as it makes auditing harder.