Rouille | Hacker News Reader

Rouille

github.com

338 pointscunidev144 comments

>You're from Quebec and don't feel at ease using only French words? Don't worry! French Rust is fully compatible with English-Rust, so you can mix both at your convenience.

Interesting factoid: in France, most of the stop signs say "stop" due to the Vienna Convention on Road Signs and Signals linked below.

In Québec, on the other hand, most of the stop signs say "Arrêt" due to nationalism reasons. Bilingual Arrêt/Stop signs exist, but are rare.

> Interesting factoid: in France, most of the stop signs say "stop", since it's a perfectly valid word in French.

Here's another interesting fact which I suspect is more of a fact than "your" fact: Almost all countries in Europe has stop signs with the word "Stop" because it was agreed upon in 1968.

https://en.m.wikipedia.org/wiki/Vienna_Convention_on_Road_Si...

Thank you. I did not know that before.

I've corrected my OP.

That is an admirably charitable response to a comment that I could not truthfully characterize the same way. Good job by you.

I mean, you weren't wrong. Stop/stopper is valid French...

Well 'stopper' is now a valid French word. No idea if it became a thing because of this or always was a thing. https://www.larousse.fr/dictionnaires/francais/stopper/74789

How you wrote this response is a bit dickish tbh.

The colloquial translation for “a stop sign” in Quebec is “un arrêt stop”

A stop stop? Doesn't even mention it's a sign?

Well in France, most people just say "un stop", you don't need to precise it is a sign, because it was originally a borrowed word

préciser = to precise

I like that. :-) Or maybe 'precisify'.

On the other hand "precisar" in Portuguese is "to need", Spanish like French is "to specify" ... keeping a slew of these cognates straight between English/Spanish/Portuguese is a harder part of dealing with all three.

"préciser" in English is "specify" in case that helps. (This has been a lovely thread!)

Oups

I usually hear people say "un stop" or "un arrêt", not both.

In Quebec we also love to take English verbs and add them to the language. If you are in front of a shop, the proper way of saying things would be: "Je vais me stationner" (I am going to park)

Here you would say something like: "J'va m' parker dan'l stationnement" (I am going to park in the parking).

The rules are somewhat simple: 1) Take the verb in English and give it a French spin (add "er" to the end)

2) Add an unnecessary second part to your sentence in French to clarify the English verb

3) Reduce the total runtime by mashing together as many syllables as you can

God I love our dialect!

Hah! Glad to hear that you folks do that out east too! I did French Immersion in SK and we usually did that when we didn't know the French verb. Our teacher would scold us for our "Franglais".

Franglais is very common here in Montreal.

In France's French, "I am going to park" is "Je vais me garer", by the way.

You sure that would not be "Je vais me garer au parking" ?

not necessarily. That would mean "I'm going to park in the parking lot". But you could also say "Je vais me garer dans la rue" - I'm going to park on the street. Anyway, in french "je vais me garer" can be translated literally in English

That means "I'm going to park in the car park.", not just "I'm going to park".

That's great. I used to do something similar in Japan when talking to Brazilian nationals. When my poor Spanish wasn't good enough to fill in with Portuguese, I'd fill in with Japanese verbs. First it was "vamos taberu" instead of "vamos comer", but then pretty soon it felt more appropriate to shorten the Japanese and say "vamos taber".

Weirdly (to me anyway), you could pretty much keep any "ne" you wanted to place after things and it worked fine, because it was a feature of both languages.

When you got _just_ the right conversation partner the little word swaps led to a lot of laughter. (We did this in English to some degree too, e.g. naru-freaking-hodo)

"Fetchez la vache!"

Indeed. In my old job, the number of times I'd hear "criss, j'ai fucké cette affaire la" or similar was beyond measure.

One interesting thing I noticed in the last few years is that the younger generation seems to have a modified version of your rule (1): they don't necessarily add the "er" part anymore (i.e. making the verb infinitive), which sounds (to me) grammatically strange and a bit confusing.

In Quebec, there is more than just French, English & bilingual stops. As an example, there are Mohawk language stops in Kahnawake.

Unrelated to Rouille, but I really like how the word factoid seems to be slowly inverting it's definition. Where it actually means an "Often thought fact that is actually incorrect", e.g. eating 8 spiders in your sleep per year. I am unsure if your fact is actually a factoid, but your comment reads as if you mean to use the word factoid in a reduced size of the word fact, it seems to mean something like; a small fact. In any case I see the word often "misused" in the latter sense. The appearant misuse of the factoid might make the newly acquired definition a ironic one, like an oxymoron.

I feel the latter definition of the word factoid feels more sensical: suffixing the word fact with -oid makes the text in which it is applied softer, where the word fact is rather harsh, the word factoid feels more friendly, like boba/ kiki, I speculate. In addition I think using more letters to address the subject you're about to share might make the reader hold its attention for longer and thus feels "right" to use in short sentences. I also feel as if I prefer to read the sentence in which it occurs with a slight upward inflection, which I find more positive.

Personally I hope the latter definition will stick and humanity is one more ironic definition richer.

I always thought “factoid” was meant to highlight the uncertainty of things you read or hear that are presented as facts.

Like a humanoid is human-shaped, a factoid is fact-shaped but not necessarily or even probably actual fact.

Thank you I really like that interpretation. I couldn't quite find it but this is splendid.

Interesting. I never thought of “factoid” that way, and if that is an alternative meaning, then the “new” version has been around a long time. My introduction to it was from reading the “Factoids” section in “3-2-1 Contact” magazine as a kid in the 80s.[0] It was my favorite part of the magazine. Let me feel smart without making much effort.

[0] https://archive.org/details/321contactjul88/page/n7/mode/2up

> Interesting factoid: in France, most of the stop signs say "stop" due to the Vienna Convention on Road Signs and Signals linked below.

While that is true, the word “stop” had been part of the French language for centuries prior to 1968. It means “halt”.

I know this is a joke. But.. when I learnt C programming, and in order to smooth transition from algo classes to practical programming, we were told to #include a header file that would more or less do what this does for rust. The header file would also enforce curly braces and parentheses when writing loops or condition statements, as far as I remember. Fact is: it actually helped. Problem: my first foray in the industry would involve C and guess what? They used english-C (sorry no better word for it) rather then french-C. I fought for a few weeks re-learning the language.

As a monolingual English speaker I often wonder about the subtleties of this dynamic among newer developers.

Is the difference in cognitive load among folks who speak different languages is consistent or even measurable? Does it bias a developer toward any specific pattern/mistake/misunderstanding/bug? Are there subtle mental-model-building advantages to decoupling software commands from their linguistic meaning through a language difference even if it's initially more difficult? Does the presence or quality of English instruction affect adoption of development beyond the first few weeks?

Could be cool to explore these things to see how they might inform pedagogy or even language design. Then again, my relatively naive suppositions might lend entirely too much weight to it.

For me most obvious implication is that I mix english and german in (internal) comments, docs and spec drafts.

I also regularly can’t recall a german word, when there is an english one that is more precise and vice versa.

As a small anecdote, it took me maybe half a decade of casual programming to realize that “yield” is an actual English word, with an actual meaning, used in real conversations, and not just a weird “programming language keyword”.

I always assumed it was just a random keyword for a programming concept. Same for “thread” by the way (also took me a while to understand how to pronounce it as I only read it).

Fascinating, I had the same problem. Programming/CS became a lot more fun when I realized that the keywords and design patterns weren’t “just words” but were inspired by some “real world” phenomena.

For me it was "deprecate", which my non-tech acquaintances didn't think was a word (they thought I meant depreciate).

Wait, those are both words? I sort of assumed the second one is a misspelling.

They mean completely different things:

> depreciate. to reduce the purchasing value of (money)

> deprecate. Computers. to cease supporting or recommending the use of (older elements, features, or versions of software)

(Source: dictionary.com)

To non-native English speakers, who often write variables and function names in their language, the language difference between keywords and the rest of their program acts as a kind of pseudo syntax highlighter: it's very easy to spot language keywords because they're in English.

Secondly the keywords don't really have any strong prior meaning to overload, so in a way they're more "pure" cognitively and easier to grok. The word "for" in everyday English really has nothing to do with "iterative loop with variable definition", the word "use" has nothing to do with symbol imports, but that's all it means to a non-English coder.

Now libraries are another thing. Typically they start using higher level abstractions that start to map to everyday constructs (eg, in a drawing library you might find things like "stroke width" which are trivial to understand for a native speaker)

For a lot of new shops in at least western countries, writing everything in english is becoming the norm, including technical docs and comments.

The two main points I’ve seen are:

- it’s a daily pain to handle two vocabulary sets and lead to undue errors and bugs. When you have a “FishingBoat” class which related to a “boat” table and all the documentation points to “Bateau de pêche” and “barque” it’s 2x harder to follow things. Then people will accidently translate “bateau” to “ship” and it slips through a few reviews of mostly independent features, and you’ll have both words in the code base before you realize.

- it becomes a swamp the day a non native speaker touches your code base. For instance you need to share part of it with a company next door that happens to be the other side of the border. Or you ask a Romanian dev team to port your code to another platform.

Yes, that is a huge problem I have seen often here in French speaking Quebec. Developers will prefer all the code in English, because the libraries and language keywords are in English and it is thus more consistent.

This leads to business domain objects to be translated in English by the devs and they will make different or incorrect translations.

Then, all the stakeholders and requirements will be in French. All developers need to constantly map the real world names to the English names used in the code base, but that nobody else uses.

This leads to bugs, inconsistencies and extra cognitive load. It comes back to how hard "naming things" is.

Yes and it makes sense because great software eventually becomes worth internationalizing. If you start with a non-English code base and documentation, good luck translating that.

> Secondly the keywords don't really have any strong prior meaning to overload, so in a way they're more "pure" cognitively and easier to grok. The word "for" in everyday English really has nothing to do with "iterative loop with variable definition", the word "use" has nothing to do with symbol imports, but that's all it means to a non-English coder.

I would disagree with this. A lot of programming keywords have enough context to help new people. I.e. "for" or "forEach" maps almost perfectly to English. "For each friend you know, call them and ask what their birthday is and what kind of cake they like".

   friends.forEach(friend => { friend.askBirthday(); friend.askFavoriteCake(); })

While loops are the same way. "While there's still boxes on the truck, you need to be moving those boxes".

It requires some slightly awkward contortions, but you can phrase English so that it somewhat resembles code.

"Use" and "import" both also have relatively clear parallels in English. import meaning bringing something from a foreign space into your own, and "use" being equivalent to using a tool.

English is my only real language (other than horribly botched Spanish) and the similarities to English really helped me when learning Python. Both in understanding and just simply remembering the keywords.

Yes for python and others whose syntax matches the language more closely. Now as for languages that talk about "virtual" "methods" of a "class"...

I think those terms are related— first entries for those terms in Oxford Languages:

method: "a particular form of procedure for accomplishing or approaching something, especially a systematic or established one."

class: "a set or category of things having some property or attribute in common and differentiated from others by kind, type, or quality."

I agree that virtual is a little shakier, but: "almost or nearly as described, but not completely or according to strict definition."

A data point from my experience. My native language is Spanish, and in +15 years I have only at one job dealt with code in a language other than English (maybe I have been lucky).

I think as a developer one quickly realizes the value of sticking with the defaults (in this case English). Like configuring your system in English to be able to google the error messages; or Excel, which changes key shortcuts based on your language (ctrl+G for Guardar, to Save; ctrl+S in English); checking documentation in English or buying books in English because they are 2-3 years earlier than the local ones.

Using an US keyboard configuration also makes it much easier to type certain common characters in programming, although that might be too much to ask for :)

In my experience, the main difference is that people not comfortable with English will spend more time on naming things and code reviews. But it tends to get better with experience.

Companies with a poor engineering culture often name things in their own language, which makes an awkward and confusing mix because everything else is in English.

I have noticed interesting regional differences too. In France it is hard to get people to use English, but otherwise the grammar is mostly fine. But in Asia it's easy to get people to use English, but it's not easy to get the grammar right. For example they have a hard time with plurals when naming variables.

Of course it's just my data point and a broad generalization, because there are also very skilled developers everywhere.

Translating C to my native language was also the first thing I did when I learnt about the preprocessor :D

I worked in Tokyo for Sony in the early 90's, when they were just getting into game consoles. Their C source files were "well documented" with code comments, but required an editor plugin to handle multiple possible character encodings for them, because this was before standards like Unicode and the Japanese language comments could be in one or more character encodings. That period was kind of haywire, because code could be copied from an email between people, but emails used other character encodings, causing a mishmash of possible comment encodings for any comment. And being a gaijin dev, I could not read the comments if they appeared correct anyway. Fun times.

When you learn it straight in English it is easier. Even if you don't speak English!

You just associate the words with what they do, but it doesn't matter what it's written. You just associate in the same way the operators +, - work in math. It just happens.

I was also subjected to that.. it was insanely verbose had to type DEBUT_BLOCK instead of { and whatnot, all that in Borland C in DOS.. insane..

A while ago I wrote Babble, a toy language to teach myself ANTLR4: https://github.com/nlehuen/babble

It initially supported both English and French keywords: https://github.com/nlehuen/babble/commit/eb090fd3e80238166ac... - that was fun but for some reason I found it cringy and removed it (as if the rest was not cringy either).

Completely off topic, but I also implemented Hodor - "Its main objective is to teach programming to Hodor.": https://github.com/nlehuen/babble/tree/hodor

They also expanded all keywords, so "fn" becomes "function", "mut" becomes "mutable" (which is not even a common word? How about "altérable" or "modifiable"?). Interestingly the Result::Err variant was kept short with Résultat::Arf which is an onomatopoeia.

10/10 looks very painful to use. Reminds me of my college days.

>You're from Quebec and don't feel at ease using only French words? Don't worry! French Rust is fully compatible with English-Rust, so you can mix both at your convenience.

This gave me a "PTSD moment" of university projects in Java with variables in French and comments in Franglais (mix of French and English). Some old teachers even made it mandatory to write comments in french (I suspect they didn't understand English beyond the language keywords).

Oh yeah. We had to do that for a big well known corporation. We had to program in English but the comments had to be in French; at least they tolerated anglicism. The result was code that only a little fraction of the population could understand, and I never heard of any software company getting sued for coding in English. What a farce.

And let's not forget when the Orifice de la Langue Française shows up to your workplace and forces to have a Frenchisation committee to set up all workstations and software in French. Googling anything was a freaking nightmare and back in the days changing the OS language was a pain in the ass.

> The result was code that only a little fraction of the population could understand

Sometimes it's better to have code comments that the little fraction can understand well, for specific purposes in an internal organization. Example, the source code used in French government for property taxes: https://github.com/etalab/taxe-fonciere/blob/master/src/EFIT...

I was a maths student and in the small programming part of the course, a friend of mine ran out of single-letter variable names and so started going through names of the lecturers he interacted with or random words like “dog” or “cat.”

You can write Perl in Latin: https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/L...

or Klingon: https://metacpan.org/pod/Lingua::tlhInganHol::yIghun

Or whitespace https://metacpan.org/pod/Acme::Bleach

No mention of the British PHP article yet‽ https://aloneonahill.com/blog/if-php-were-british/

First, the readme is simply hilarious!

Jokes asides, the concept underlying this project is actually interesting. It wouldn't be bad at all if programming languages were localizable.

I think it would help many if it was possible to choose the (human) language in which to use a programming language. Ideally, the same source code could be viewed in different languages depending on the preferred idiom of the developer.

> It wouldn't be bad at all if programming languages were localizable

That is an admirable dream to have, and one that I have sometimes had myself. Unfortunately, as with most things reality soon puts an end to it.

First, the dream is only really a dream you can have with the luxury of a Western language. It is unlikely to be viable once you start looking further East in the direction of e.g. Kartvelian languages (i.e. low number of speakers worldwide and even fewer with relevant specialisms in programming to write compilers) or Asian languages (e.g. Japanese and its particles and other complexities).

Second, when you are writing code you don't really want to have to worry about the possibility of debugging your compiler. Sticking to English means the likelyhood of a more robust compiler because of more widespread adoption. You also remove technicalities such as UTF-8 or whatever else that might cause indirect issues.

Its a bit like science really. Sure you can write your papers in your native language, but the reality is if you're serious about your work being discovered and are interested in being offered bigger and better jobs, you'll want to publish in English sooner rather than later.

> Unfortunately, as with most things reality soon puts an end to it.

Usually, when a thing gets labeled as a dream, people don't try very hard either.

> Sticking to English means the likelyhood of a more robust compiler because of more widespread adoption.

The comment you quote specifically talks about localizable software, not having one compiler per language. When you I18n a website, you don't write n sites, for instance.

> Usually, when a thing gets labeled as a dream, people don't try very hard either.

Some things are hard, but worth trying.

Other things are a dream because the reality is they are unachievable either due to the realities of practical constraints or because the amount of work involved would be hugely disproportionate to the benefit.

For example, I mentioned Kartvelian languages. How about we specifically look at Laz which according to Wikipedia at the last count in 1980 had only 22,000 native speakers.

Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work".

> the amount of work involved would be hugely disproportionate to the benefit.

And you can trust english speakers to properly assess the benefits of I18N, right?

> Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work".

As I said in the message you quote, internationalizing a compiler is not the same as rewriting it. If you consider that making languages accessible to other languages means each natural language should have its own programming language and compiler, of course it's going to be hard.

But that's moving the goalposts.

First off, you don't need to port a programming language to every natural language. Some smaller goals would already help. For instance, making it easy for third parties to i18n the language and libraries would be a significant enabler.

> Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work".

This seems like letting the perfect be the enemy of the good. "We can't possibly localize for every possible language ever" is not much of an argument for why localization itself isn't worth it.

IIRC, TI Basic dynamically translated keywords (and probably function names) depending on the current langage.

That's less interesting if you have lots of libraries if you don't translate them.

> It wouldn't be bad at all if programming languages were localizable.

Go switch Excel or Google Sheets into a language you don't know. Then try to use formulas with them.

Come back and tell me if localized programming languages are a good thing after that. :D

> Go switch Excel or Google Sheets into a language you don't know.

I don't believe that point supports your claim. Switching excel to a language you don't know is a good example of the benefits people who don't speak english get from localized languages, not the other way around.

> Come back and tell me if localized programming languages are a good thing after that. :D

The truth is that localized excel has enabled a generation of people speaking poor english to still do pretty dope stuff for their business.

Likewise, localizable languages for children (e.g. Hedi) work pretty well at helping children discover computers before they have a firm grasp of english.

And it makes support, reusable code, common understanding, and readability (in a team) fly out the window, and increases the amount of development overhead of whomever has to maintain the language.

Only if the said support and code are not localized too. I'm using all my devices in English because it's easier to find help online but I can see why people less proficient in it would prefer localized software down to formulae and documentation.

> it makes support

Support is already a problem currently, because personalized error messages are less searchable but more useful than generic ones. Moving to error codes is a good example of an orthogonal concern that would incidentally help i18n. Supporting error formats that can be treated by machines is a further unrelated step that would also benefit i18n.

So I would say the stuff we already do tend to make this concern less relevant.

> reusable code

That's an orthogonal concern. You don't write new code when you i18n something, you just create dictionaries.

> common understanding, and readability (in a team)

I don't believe anyone is making the point that one team should write in separate languages. However, a team able to choose its own language (possibly the one used by the rest of the business) is a plus.

In non-english countries, it's very common to have code written in english to describe a business that is done in local language, with really bad translations of business terms. This already causes issues.

> increases the amount of development overhead of whomever has to maintain the language.

Why would the language maintainer do the i18n themselves?

> orthogonal concern

Sorry to be blunt, but you have no idea of what you are talking about.

> You don't write new code when you i18n something, you just create dictionaries.

No. i18n is not that easy, sorry. I wish it were.

To be frank, this answer reads as though it was written by someone who has not done any extensive i18n work in their life. Languages are not 1:1 translatable. This goes beyond words and phrases - numbers, math, time, dates, names, grammar, etc. are all completely unrecognizable between certain languages.

It's not a problem that even regular software has solved generically and elegantly, and then going on to apply it to programming language design is a completely different beast, with its own set of problems.

> this answer reads as though it was written by someone who has not done any extensive i18n work in their life. Languages are not 1:1 translatable.

I argue that i18n is not translation.

It seems like you're making a point for solving problems beyond the scope of PL internationalization, including problems that are not solved when it comes to how english code translates to english natural language.

My original point is that foreign excel versions already did help people. From there, improving compilers to make that work easier and less costly is a reasonable goal, or at least a tractable one. Some of that work is already being done for unrelated reasons (e.g. modern compilers offer interfaces for LSPs as well as error messages in formats that allow processing beyond reading for CIs — both of these changes benefit potential i18n efforts).

> The truth is that localized excel has enabled a generation of people speaking poor english to still do pretty dope stuff for their business.

I got paid a lot to transform projects that used abusively Excel sheets. All of them had absurdly long delay and cost explosions caused by this.

Excel sheets are for small business and small projects by non-programmers. Excel sheets in a non-English language are for small businesses and small projects by non-programmers that are doomed to stay this way. This is because having programmers that want to unfuck a mess of macro AND speaking your foreign language simply are very rare AND doing so before the business implodes are very slim.

> I got paid a lot to transform projects that used abusively Excel sheets.

I wonder where all this money came from.

I also got paid a lot to transform projects that abused excel, among other things. The usual truth was that, without excel (or, on other projects, without their tortured python scripts, or without the off-the-shelf software modded to death), these companies would never have built a business successful enough to pay entire teams for months or years before any returns.

> having programmers that want to unfuck a mess of macro AND speaking your foreign language

I mean, at which point did the idea "Oh, that language is so weird that very few can possibly speak it _and_ learn to program" start to make sense to you?

Did it ever occur to you that my foreign language was the first language of a whole lot of people living in my country, and that maybe there are a few good universities here?

Switch back to a langage you know?

> It wouldn't be bad at all if programming languages were localizable.

It wouldn't be bad indeed, it would be terrible.

I wouldn't be against some IDE add-ons allowing you to see the keywords in your language if you wish, but the underlying names should stay in english. And the function names as well. Otherwise:

- you duplicate the documentation effort, which is already a burden;

- you make googling things extra hard

- people will use their language features, which means non ascii chars. Good luck typing "La leçon du père noël à l'école de la forêt" with something else than my french keyboard.

- IT is nothing but thousands of conventions glued together. And names are a hell of a shortcut to describe conventions. Break that and you destroy trust, reliability and productivity.

- you split the community. FOSS works so well because we can collaborate so well: we have one rosetta stone that lets us do so. Is has a basic alphabet, few rules, and is quite easy to learn.

I'm a french Python dev, and Python 3 does allow you to write variables names with french accents. I would never do that, and really hope nobody ever does.

I'm also a french developer and though i've been very pedantic in the past against non-english code, I must say today that I really prefer "french" well expressed code over "english" code full of errors, "faux amis" everywhere and wrongly expressed intentions.

The kind of code you talk about are usually internal only. People don't write libs, framework or main stream language in those situation.

In that case, then it's ok to bite the bullet, to avoid the worst case scenario. But you are already in a bad place to start with. Because if you put in prod some code by somebody who can't write english properly, then it means your team doesn't have access to most information resources in the world.

So your problem here is damage control, hardly a situation to generalize from.

There’s a lot (maybe a majority where I live) of people who can perfectly read and understand English but not write a single sentence without making errors.

Bad written code is bad written code in any language, that's a false comparison.

What I meant is that the same non English native developer can write totally well expressed code in $native_lang but also full of nonsense code in English.

In that case I'll make an exception, but this is actually very rare. I can see a clear correlation between terrible english and terrible code.

I almost entirely agree, though I think your third point (typing non-ascii characters) could be less severe with one extra lesson in the typing course most kids are forced to take. When I first took French in 7th grade somehow I learned online you could enter ascii codes (whatever those were) on Windows with alt+numpad, and I still have memorized that alt+130 gives é. Later I moved to Linux where we have a great Compose key system, so I can just type <compose> + e + ' and get é, <compose> + c + , to get ç, and so on, with <compose> mapped to whatever I like (currently right-alt). Supposedly (haven't tried it) this system now has a Windows port: https://github.com/samhocevar/wincompose

Asian languages are harder. But if you're told about IME, then at least if you know what you want to type, how to actually type it isn't a big burden. IME can also help with rarer math symbols like ⋂ (\bigcap) ≅ (\cong) or ⊵ (\unrhd), or is another way to get something like the compose key system.

That's a recipe for combinatorial explosion: each language has special chars or even are just made if glyphs, are you going to learn them all? Do you want to impose the burden for all devs in the world?

And now your typing is not at all fluid, even if you didn't have to stop and thing about every single special characters (which most people do), you will have to enter a combination to get them every time completion can't help.

In fact, even with an AZERTY keyboard, typing French, my native language, is slower than english.

Instead of having one simple common ground, you also now have an infinite number of variations to care about.

Not to mention having to understand a lib in spanish, an another one in russian and a last one in Hindi or arab.

I don't need to learn them all, I just need to know the ones I expect I need to type in for the foreseeable future. I might even forget them later (as I've forgotten a lot of LaTeX mappings, fortunately there's a cheat sheet).

You're just repeating your other points about the problems that come from having so many languages, which I mostly agree with, but typing at least is not really an issue, which is all my point is. The issue is: "do I know Arabic?" not "I know Arabic, can I type it?"

As for your experience with French, maybe the AZERTY layout is just inherently bad, but how much slower is it really? Typing your example sentence with my compose key takes me about 3x longer than ignoring the accented characters entirely, which is more than I expected, though I'm very unpracticed. With Japanese, which I'm even more of a noob at, nevertheless the overhead is smaller. If I wanted to type 'purple', I hit a chord to enter JP IME mode if I'm not in it already, type 'murasaki' (the romanized version of the word) at full speed, and leave it as むらさき or select from kanji completions to get 紫 or maybe I needed it to be in katakana so I hit F7, finally I commit it and move on. It may seem like a lot but whatever the case it's a really tiny overhead from just typing 'murasaki'. In practice though looking at source code from Japanese developers I see a mix of full English (maybe some Japanese comments, maybe not), some mix of Japanese but always using romanized symbol names, and full-on variable and function names are in actual Japanese. Because the overhead of typing is so small though, I don't have a preference for the second or third option, they're both fine, though of course selfishly I'd love for the whole world to understand and use English exclusively. For the French case, even with an overhead of 3x in the worst case, I wouldn't object to a variable with an é in it.

I know a lot of devs that don't even type with 5 fingers, you are apparently well trained with your keyboard and you take a X3 hit.

> Good luck typing "La leçon du père noël à l'école de la forêt" with something else than my french keyboard.

There's key bindings for a regular qwerty keyboard that lets you compose letters and symbols to make accents. It's very easy to write French (with all the accents) on a US keyboard (on Gnome Intl. Alt keyboard with dead keys I believe).

French here. I've an American keyboard, not only because my company language is english, but especially because writing code on a US layout is from far the best. [], {}, () can be typed directly or by pressing shift. On a French keyboard, you've the additional Alt-GR key which must be used (second Alt key), which makes some keys awkward to type efficiently - if you've a MacBook, the Alt-Gr key doesn't event exist, which makes writing code a nightmare ([ and { just don't exist!!).

Then, numbers which are very common to type when writing code must be typed by pressing shift. A French keyboard is made to write French efficiently, arguably English too, but definitely not to write code.

I very much long for a French keyboard designed for coding ...

A French equivalent of the "Polish Hacking keyboard"? Never used it (not even remotely Polish), but I know several people who speak well of it.

Québecois here, for me I have to switch between English and French all the time and pressing Alt do ~{}[] and Shift for <>()| has become a second nature. I just don't think about it anymore and I have to say that when I have to use a US keyboard I just feel so limited.

The problem with US keyboard is that it's most of the time an ANSI layout, with a missing key between Z and left-shift. I love the CSA keyboard because letters with accents are in direct access (a lot better than French Azerty) and {}[]() are positioned logically.

French here using US keyboard with Compose key. Works like a charm.

Easy doesn't mean productive. My guess is that you take 2 to 3 times longer to time such sentence.

Versus using an azerty keyboard or another French-specific layout? Yeah, it's a tad slower. But it's a hell of a lot quicker than trying to look up/remember alt-codes or something. Writing in 2 languages with one keyboard is never going to be optimal.

And 2-3 times longer? Most sentences in French don't have that many accents, the example picked was a rare one.

Yes but we are talking about putting them in code symbols in the first place.

I had a computer with an US ANSI keyboard a few years and I don't remember it to be very easy. It's annoying to compose accents, it's worse when you have to switch to another OS or another computer. On Windows, it's a mess when you have more than one keyboard layout activated. And it's terrible when you have to type « » or æ œ like : « J'ai mangé des œufs pour Noël »

I just set the input language to French and let autocorrect add the accents, 99% of the time, it gets it right as there are not that many words where the accents change a word into a completely different word. The only one I can think of is marche as in walking vs marché as in a market.

Early VBA did this, apparently - see https://ericlippert.com/2021/02/17/life-part-38/#comment-119... on Eric Lippert's blog.

> It wouldn't be bad at all if programming languages were localizable.

What a terrible idea.

I'm curious, do you speak another language? Anyway, I think the history of programming languages indicates that it wouldn't be all that helpful, simply because nothing's really caught on, despite many opportunities. What does seem useful is being able to have a way of representing non-ascii characters in source code, at least with comments but hopefully with symbols and of course with data, but even in languages that let you trivially define your own names for everything including the basic keywords and standard functions, you don't really see localization attempts or non-English speakers caring. It's more than good enough to just have native-language documentation that explains the concepts behind the English tokens; you need this in English too since it's not like there's always a clear direct correspondence between the English dictionary meaning(s) and the programming language's meaning(s) of the same word/abbreviation.

AppleScript had this! But they ended up not shipping it.

Rouille is also best deployed using Marcel.

https://github.com/brouberol/marcel

This used to be a lot more common in the early days of computer science teaching, where you had localized versions of Pascal or Basic.

For an extreme version of this, where the language isn't just used to replace a few keywords, there's always Linga::Romana::Perligata.

https://users.monash.edu/~damian/papers/HTML/Perligata.html

A curious thing about programming is that it became prominent when English dominated academia (and computer science was extremely American.) Compare this to, for example, mathematics where:

- some words are loaned from another language like Eigenvector or group (sort of—I think it came from the French groupe). Also eg a blackboard-bold Z (for Zahlen) or Q (for quoziente) for integers or rationals

- other words are taken from the native language (eg rational or probability or field extension) though they may derive from Greek or Latin and have cognates in other languages.

- some symbols are quite universal and used in every language (eg the forall or exists or implies symbols)

- I don’t know whether letters that are typically used for things are the same (eg I don’t know why density is often rho. Is it referring to a word in a different language)

- the proofs are written in the native language and often that part matters a lot.

- so much stuff is named after people so words don’t need to be translated (eg noetherian domains or Cauchy–Schwarz)

- I wonder if some theorems get different names? (I assume in China they don’t call it Chinese remainder theorem)

> I assume in China they don’t call it Chinese remainder theorem

Apparently they are! “中国剩余定理” according to Wikipedia, where the first two letters mean China.

https://zh.wikipedia.org/wiki/%E4%B8%AD%E5%9B%BD%E5%89%A9%E4...

In elementary school it was just 余数定理 without the Chinese. Well, academia sounding more foreign is normal here.

And now there is a german fork as well: https://github.com/michidk/rost/

Does one of you remember WinDev? Their programming language (WLangage IIRC?) and APIs were available in multiple language, I had to use the French version. It was really a horrible experience to always have to check the language spec to lookup for their weirdly translated keywords.

I would definitely not recommend.

> were

Nope, WinDev is still alive. The latest version is from December 2020

Wow, that’s insane! I never thought they would survive that long. I remember that we had to use a dongle to enable the license, you could only use their IDE if you had it plugged in, which was a real pain.

Also, their monthly magazines were the most sexist stuff I’ve ever seen… hopefully that changed…

I do, I worked with it until a few months ago.

I wish this was a joke but actually reading upon the french governments plans i‘m not entirely sure anymore

Il y a même les accents, bravo ! Merde à Rouille !

No, you meant : "Rouille, c'est vraiment LA merde !"

Which, of course, while it is a diret word-for-word translation, has perfectly antinomic meaning in each language.

For those wondering:

* "c'est la merde" : "we're in trouble"

* "c'est de la merde" : it's shit

* "Je te dis merde" : well... "F*ck you" or "all the best", depending on context.

Yes, for real ^^

(edit: formatting)

I think you missed more than a few xcambiar !

e.g. "écoute ce que je te dis, merde" ... ending sounds the same as your example "je te dis merde" but totally different meaning.

Indeed, but merde is such a versatile word, it's hard to be exhaustive.

Thanks for your addition!

"Je te dis merde" before a performance would translate to "break a leg".

The supersition goes that you should not reply with "merci" ("thanks") but "je prends" ("I'll take it ?")

There are unverifiable explanations for why "merde" is used by actors ; my favorite one is that it is related to horse carriage carrying theatre-viewers to the theatres ; you're wishing actors that a lot of horse will carry a lot of viewers, and do the other thing...

Oh thanks, I always assumed the carriage explanation was verified.

Do you know of others you could share, before I google it?

Awesome idea and well realized.

In my consulting days I met a number of customers in Quebec who were coding with French method names, variables and such. They were even using accented names for variables. I actually think if they get onto Rouille they might start using it. That's scary but at least, it would look less bancal.

I can bet you can find the same use case in all other languages, so we need Óxido and 锈

Edit: LOL just discovered there are a few of these already https://github.com/bnjbvr/rouille/network/members

People are probably going to say this is silly (and maybe the author would say the same), but I think it's an awesome demonstration of what Rust macros can do, and I think it could also become genuinely useful for non-English speakers who want to write code in an English-centric landscape. Most people in France and Quebec probably know enough English to work with English keywords in code, but I bet for people in lots of non-western countries it can be a real hurdle in terms of approachability and readability.

If you like this, check out قلب [The current name قلب means Heart, but is actually a recursive acronym for قلب: لغة برمجة pronounced 'alb: lughat barmajeh meaning Heart: A Programming Language].

https://nas.sr/%D9%82%D9%84%D8%A8/ https://github.com/nasser/---

If this is a Brice de Nice reference I'm going to lose it.

https://github.com/bnjbvr/rouille/commit/3d67732c593a78f0545...

It's even more funny looking at the commit itself. Thanks for the pointer!

Although technically speaking, it's a contre-casse!

I don't think "PeutÊtre<T>" is a good substitute for Option<T>. The direct translation is Maybe<T>. Maybe<T> is used in Haskell. Haskell was made in the UK. There's no way we could accept this for our French language.

I really thought this was about the web server framework https://github.com/tomaka/rouille, that's been around for ages.

There could be a compiler flag to parse keywords in another language.

Native English speakers are quite lucky all programming languages are in English. Imagine China created their own languages and OS? We couldn't keep up

> Imagine China created their own languages

文言 is programming in classical chinese. So its starting… :)

https://wy-lang.org/

This must be what the Merovingian codes in.

> fonction écrire(

I love how in the README, the syntax highlighter doesn't pick up letters with diacritical marks.

Someone from Italy should make a fork of Java called "Cappuccino"?

You do realise that 'Java' was (is?) not originally an English word?

You know nobody's intended to use it when it has WTFPL

C'est magnifique !

As a !Quebequois I was disappointed that the Readme was in English.

>Would you like to try something different, in an exotic and funny-sounding language?

Casually derogatory joke, a classic.

Reply on news.ycombinator.com