Rather than just translating keywords, it lets you write code that actually uses Korean grammar. For example, "10을 5로 나누고 출력하다" (literally "10 by 5 divide and print") outputs "2".

You might already know this, but there's also a Korean programming language called 'Yaksok'. Here's a 2048 written entirely in Korean: https://github.com/yaksok/yaksok/blob/master/code_examples/2...

Nouns translate fairly naturally, but standalone verb commands in English need more care. In English, a verb like "find" can stand alone, but in Korean a verb usually needs an ending, and different endings can sound quite different or awkward depending on context. For example, "find" could become 찾다, 찾기, or 찾음, but those are not interchangeable.

Plural forms are also tricky. English distinguishes strongly between singular and plural, but Korean usually does not. Explicit plurals like “단어들” often sound unnatural unless the individuality of each item is important.And it feel same with "단어목록"

Overall, this is a very interesting project with real potential. I think it could become even stronger if it considers the structural differences between English and Korean, rather than treating it as simple keyword substitution.

    # def two_sum(arr: list[int], target: int) -> list[int]:
    펀크 투섬(아래이: 목록[정수], 타개트: 정수) -> 목록[정수]:
    # n = len(arr)
    ㄴ = 길이(아래이)

    # start, end = 0, n - 1
    시작, 끝 = 0, ㄴ - 1
    # while start < end:
    동안 시작 < 끝:

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.

The downside is understanding logic feels harder because - the order of Korean is diff from English - e.g. "동안" (while) hard to reason about as "동안" comes after the condition in Korean linguistics and comes before in English.

So my only suggestion is to go diff direction from normal writing flow as shown below for readability

- from: 동안 n < 5 - to : n < 5 동안

It’s fun to look at your code samples, have absolutely no clue what any of it means, and think about just how many non-English-speaking programmers must have felt that way looking at our all-English programming languages.

Except lisp: that’s just inscrutable symbols like cond and cons and car and cadr and a bunch of parens! :-)

I suppose is again why I discuss with everyone as I would like to have a single language in the world, it would reduce wars, miscommunications, bound everyone closer. But ofc, the other point of view is that it reduces culture But I think it would happen as UK/US or Spanish, same language with variations, but everyone can understand each other.

I can't imagine what would have happened if Python or JS had been fragmented into X different languages because of egos, and instead of collaborating, decide each to create their own languages. I don't think we would be where we are today, probably AIs would not be around, since we would be fighting to understand so many different programming languages.

Hangul's phonetic symbolic design: https://news.ycombinator.com/item?id=47382219

Korean plural forms: https://news.ycombinator.com/item?id=47386312

Your comment on how LLM tokenizers shorten common inputs in training data; Korean is more visually compact but suffers from poor token compression: https://news.ycombinator.com/item?id=47381843

Hangul keyboard layout - so cool that the layout is split between consonant and vowel hands and forms rhythmic harmony while typing: https://news.ycombinator.com/item?id=47382081

I replied that for Japanese at least, probably due to symbol input being too tedious. However I think it's worth mentioning a potential mitigation, and maybe even an advantage.

As a mitigation, full-width symbols could be used instead, which are typically the default in Japanese input. Japanese itself is also fixed-width so if done across the board the language itself becomes fixed-width, not just by virtue of a font selection.

As an advantage, some logical symbols, greek letters, other rare characters are easy to input in Japanese mode, and this could lend itself to a more symbol-heavy language design. I already take advantage of this myself with Δ, φ, and τ use selectively in a few projects. Symbols with easy entry may differ by OS, but here are a few other examples that could be useful:

≠, ≡, ∞, ∴, λ, θ, α, β, ・, °, ※

https://github.com/farant/rhubarb/blob/main/include/latina.h

edit: oh, maybe you can’t do full unicode. that’s too bad!

Perhaps look to APL for efficient ways to represent math concepts/structures?

This seems like a reasonably good security measure too

* , realy hope this isn't unforgiveably offensive.

Amazing though!