Scratch supports Korean, but Scratch benefits from using JSON instead of bytes or code points to serialize programs, which allows the user to change their display language (similar to how hard tabs let users set indentation size).

There's probably a lot of reasons why non English programmers stick with English keywords, beyond just language/tooling support. Learning new keywords is already part of learning a programming language, and much of the documentation and resources available for languages and libraries are only in English. ASCII-only strings are still ubiquitous in software, like URLs and usernames. And in international teams, English is the go-to lingua franca.

Could this change with LLMs? Maybe, but most code in its training data is in English, so LLMs likely work most effectively in English.

Good point about compactness — 실명인증계정생성 vs AbstractVerifiedIdentityAccountFactory is a real example where Korean shines.

One distinction though: Han uses actual Korean words, not transliterations. 함수 means "function" in Korean, 만약 means "if" — they're real words Korean speakers already know.

Your example uses transliterations like 펀크 and 아래이 which would look odd to a Korean reader. That difference matters for readability.

Using actual Korean words rather than transliterations greatly aids readability --- I can still remember stumbling over the transliteration of "Walker Hotel" when taking Korean at the Presidio of Monterey, and pretty much everyone else had the same problem.

It's been tried with Chinese Python back in the early 2000s: http://reganmian.net/blog/2008/11/21/chinese-python-translat...

It never really took off. I think because computers already require users to read and type Latin letters in lots of other situations, and it's not that hard to learn what a few keywords mean, so you might as well stick with the English keywords everyone else is using.

It might not be hard to learn the keywords in an English programming language but it seems hard to learn something like Spring Boot

There has been more recent interest expressed as well, but still with no momentum as far as I can tell. E.g.: https://discuss.python.org/t/supporting-non-english-developm...

I think the actual reason it has not taken off is because of the ecosystem. You can translate Python, but nobody using a high-level language like Python uses just Python. The first time you pull in a library and are met with a wall of English documentation, error codes, and APIs, you're right back to where you started. Low-level OS APIs are also in English. I suspect there is a lot of potential being left on the table here, but it's a massive undertaking because you need to translate not only a language but also enough of an ecosystem for people to be able to make programs.

That probably pops up all over the place, like how there's no real progress making the terminal support different keyboards/languages (e.g. send raw key code to terminal apps).

Technical people already have to make concessions to deal with ascii chars and English in computing by the time they use a terminal, so the upside of changing any one thing kinda peters out.

People act like the keywords are the hard part. They aren't, and once you get past 'for' and 'if' the rest of the toolchain still lands in English: package docs, compiler errors, logs, blog posts, and ten years of answers on Stack Overflow.

Changing syntax doesn't change the surrounding world. Unless you plan to translate half of pip and npm you mostly end up with a teaching language or a local curiosity.

funny examples, though.

I can't speak to Korean, but thinking about Japanese, one probable reason it wouldn't catch on is how tedious and inefficient it would be to constantly switch between input modes. Japanese input mode is designed for prose, and isn't well-suited to efficiently entering the symbols commonly used in programming. Even spaces. It results in needing a lot of extra keystrokes.