A simple translation of keywords seems straightforward, I wonder why it's not standard.
# def two_sum(arr: list[int], target: int) -> list[int]:
펀크 투섬(아래이: 목록[정수], 타개트: 정수) -> 목록[정수]:
# n = len(arr)
ㄴ = 길이(아래이)
# start, end = 0, n - 1
시작, 끝 = 0, ㄴ - 1
# while start < end:
동안 시작 < 끝:
Code would be more compact, allowing things like more descriptive keywords e.g.
AbstractVerifiedIdentityAccountFactory vs 실명인증계정생성, but we'd lose out on the nice upper/lowercase distinction.
I hear that information processing speed is nearly the same across all languages though regardless of density, so in terms of processing speed, may not make much difference.
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.
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.
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.
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.
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.
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.
I hear that information processing speed is nearly the same across all languages though regardless of density, so in terms of processing speed, may not make much difference.