Three prevailing themes in the discussion
| Theme | Key points | Representative quotes |
|---|---|---|
| Token‑efficiency & LLM tokenizers | Korean‑keyword code does not cut prompt size; the benefit is a training‑data bias, not Hangul itself. | “I actually tested this with GPT‑4o’s tokenizer, and the result was the opposite — Korean keywords average 2‑3 tokens vs 1 for English.” – xodn348 |
| Tokenizers trained on English merge common words into single tokens; Hangul syllables split into 2‑3 byte‑level tokens. | “It’s a tokenizer training bias, not a property of Hangul itself.” – xodn348 | |
| Readability, typing ergonomics, and learning | Korean speakers can read code as natural language; Hangul’s keyboard layout and phonetic design aid fast typing, but it doesn’t reduce keystrokes for non‑Korean users. | “The main benefit of Korean actually comes from the fact that the language itself fits perfectly into a standard 27 alphabet keys and laid out in such a way that lets you type ridiculously fast.” – bbrodriguez |
| Using real Korean words (not transliterations) improves readability for native speakers. | “Using actual Korean words rather than transliterations greatly aids readability.” – WillAdams | |
| Ecosystem & practical adoption | The lack of a Korean‑centric ecosystem (libraries, docs, error messages) and the dominance of English in tooling make widespread adoption difficult. | “I think the actual reason it has not taken off is because of the ecosystem.” – applfanboysbgon |
| Even if keywords were translated, the surrounding world (APIs, docs, Stack Overflow) remains English‑centric. | “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.” – hrmtst93837 |
These three themes—tokenizer bias, readability/typing ergonomics, and ecosystem constraints—capture the core of the conversation around the Korean‑keyword programming language project.