Hacker News Reader

> I am really stoked for the future of programming languages, when localization is just a matter of translating some words.

My experience with localised codebases (in my native language) have been horrifying - like it or not terminology is developed in EN, you either get unnatural sounding "borrow" words and the translation is pointless or worse you get people coining new terminology nobody but them understands. Not to mention fragmented communities, knowledge bases, etc.

IMO localised codebases would be a regression not progress and I dread every time I see Chinese in a codebase (simply because they are a large enough market to split the dev community)

Yeah world languages like Chinese, Russian, Arabic have a chance of building their own thriving developer communities, but for a language like Italian, or even German, forget it. It's too small to be up to a language with 10 times as many speakers. Writing in the local language would put you at a disadvantage far more than you are at a disadvantage by being second speaker of a language.

> I dread every time I see Chinese in a codebase (simply because they are a large enough market to split the dev community)

They aren't going to split it, the rest of us will adapt. English was arbitrary, so was French and Latin and Greek before it. Probably in the form of some Romaji-like equivalent (ideograms are too high a bar) but we will start to adopt it. The largest economy dictates the lingua franca because they produce the most output.

It's a pretty amazing coincidence how it just so happens that English is (one of) the most convenient languages to encode into bytes.

How is that? I don't know about Chinese, but surely Japanese has much better entropy in bytes? As would other languages with more expressive character sets.

That's the issue. English can be represented with 7 bits. Good luck doing that for any logographic language.

And that doesn't even take into account that since English (and a lot of alphabet based languages) use spaces to mark where words begin and end. In Japanese, you can have a word that consists of a kanji plus a few hiragana characters as a grammatical marker. But there's no space between that word and the next. How do you know decide where to insert a line break?

It's not a coincidence, the A in ASCII stands for American.

Sure, but just the fact that roman characters with no accents (or just a few), plus all of the punctuation, fits in a 7 or 8 bit key space.

And even 5 bits was enough for a long time, across a few European languages: https://en.wikipedia.org/wiki/Baudot_code (which I just learned is also where "baud" comes from!)

Is it more convenient than any other phonetic script? I just happened that ASCII was based on English and became the standard.

> English was arbitrary, so was French and Latin and Greek before it.

Might be arbitrary but there isn't really a good reason to change. Compared to the past, right now we have way more people than ever before from around the planet being able to communicate in a single language - English might not be everyone's first language, but it is a fine second language (if anything i'm certain that there are way more people speaking English as a second language than there are people speaking it as a first language).

The main point of a language is communication, why spoil that?

(and FWIW my first language isn't English but i have worked in a couple of other countries with other people whose first language also wasn't English - actually it was several different languages - yet thanks to English everyone was able to communicate, which i think is something to be treasured, not try to disrupt... i mean... we're just discussing things here in English after all)

right now we have way more people than ever before from around the planet being able to communicate in a single language

My father worked in international trading. He would talk (or Telex) with people in 50 different countries each week. He always said, "English is the international language."

Because this is not an arbitrary decision made by someone, but a natural, almost unavoidable process.

> They aren't going to split it, the rest of us will adapt

Yup, but there's no real reason to go from one arbitrary language to another (and I'm saying this as someone who struggles to learn languages, and English was definitely not my first).

So it would be a straight set back (overhead of switching), for no real benefit (arbitrary to arbitrary).

Another big issue is the split in resources. Right now, anyone can learn English and get access to most programming resources. You can post your code online and get the majority of the programming community to help around the world. A long time (10 years+) ago, I was heavily involved in forums for a programming language that had a large amount of Chinese developers. They'd post their code, and to help them I'd have to start pattern matching symbols to try to figure out which function was which (or paste it in my IDE and use my IDE's tools to figure it out). It was suboptimal at best. Starting over with all the community building that's been done would be a major (if temporary) set back, in a field that reinvents the wheel way too much as it is.

I realize being able to learn English is a privilege, and requiring it acts as a form of gate keeping. But having everyone on the same natural language provides a fantastic global maximum (at the cost of gate keeping at the local level), and no matter which language it is, someone will have to learn it. Furthermore, asking people who went through the trouble to learn this one, to learn ANOTHER is even worse (if also temporary)

> So it would be a straight set back (overhead of switching), for no real benefit (arbitrary to arbitrary).

The convenience of the millions of Chinese speakers dwarfs your inconvenience. That is why it will happen.

Already there are plenty of data sheets for electronic components where the English is barebones and there is a lot more Chinese text. Presumably, most of their customers are Chinese and thus their effort goes there. It makes me tempted to learn to read it so I can make use of it... but electronics for me is just a hobby.

Latin is still in use in science, medicine and law, and "the economy" behind it was destroyed some 1500 years ago...

>Probably in the form of some Romaji-like equivalent (ideograms are too high a bar) but we will start to adopt it.

CCP will make you adopt it as-is, or GTFO.

I find it interesting their approach to language compared to Japanese. Modern Japanese borrows so heavily from English, especially if you're doing technical work.

Chinese, at the governments request, hasn't done that. Instead new words are coined as needed. They're keen on protecting the language.

Under the hash system it would be trivial to change it back though. Of course it doesn't solve the problem of variable names...

And comments, and documentation, and stack overflow, and blog posts talking about your problem, and books, and so on. No, the cost caused by translation is not just solved by some function content hashing.

Do you know how they would hash a recursive function? Or where I can learn about this? Thanks!

EDIT: I am asking more about the hashing function than about the language. Because if there is a recursive function, that means that one would need the hash of itself in order to compute its own hash. One can probably try to compute a hash iteratively until a fixed-point is achieved.

EDIT2: but... it is probably a bad idea to do that.

It's an interesting question that I don't have an answer to. I don't actually know what this technique is called - I heard about in passing at lambda conf, and just saw last week that Unison is using it.

The unison crew is super friendly (Runar once patiently spent 20 minutes trying to explain adjunctions to me, a perfect stranger). I'll ask in their slack channel if this has a name.

Thanks! I'll try to join their slack after work :)

I also was interested in the answer to this, which turns out to be here:

https://www.unisonweb.org/docs/faq/#how-does-hashing-work-fo...

Tldr: A singly-recursive function works just fine: the current function has a name at hashing time which it can use to refer to itself. A set of mutually recursive functions gets hashed all together as a "cycle", and to refer to one of those functions you need the hash of the cycle plus an index representing which function in the cycle you want to call.

Localization of code language is a horrible idea, no matter how nice the intention sounds.

English is as sort of like an international ISO standard to write code in - most people can read it, comment on it, audit it, etc. If people feel, they can write comments in their native language.

The entire reason why we have had such a great open source collaboration on global scale is because everyone is speaking the same code language.

So these functions get the same name then:

  def following_index(i: Int) = i + 1

  def item_count_with_free_gift(n: Int) = i + 1

It would be easy enough to have multiple aliases for the same function. They can be named whatever you want, they just have the same identity

> So these functions get the same name then:

    >  def following_index(i: Int) = i + 1

    >  def item_count_with_free_gift(n: Int) = i + 1

They'd better not get the same name, since one increments its argument and the other one increments an auxiliary variable ….

I am very good professional programmer A++++.

localization problem? i believe that is an invented problem. why would anyone write code in his/her native language?

> why would anyone write code in his/her native language?

Well, actually, a lot of people already do.

I think VBA does this. E.g. the name of excel functions are localized.

Yes, appshare.co stores code as a hash as well. We were inspired by Unison so full credit goes to them

even better make the hash a rolling locality sensitive hash based on the input to the function to find similar functions, etc.