PTT動漫區 / C_Chat (希洽)

Re: [閒聊] 玩日文遊戲沒有漢字 是不是反而困擾？

看板C_Chat (希洽)作者 (arthur)時間7小時前 (2026/03/01 08:16), 5小時前編輯推噓-5(3推 8噓 38→)
留言49則, 4人參與, 5小時前最新討論串5/7 (看更多)
※ 引述《jpopaholic (日音スキ)》之銘言： 43 日文的效率並不高,日文的特性是比中文更模糊 而模糊的好處就是能減少人際關係間的摩擦,促進社會和諧 因為太刨根究底得理不饒人,就容易起衝突 而從人類社會發展的觀點來看 人類的資訊越來越依賴紙本和電腦的記憶 人類在網路上互相溝通的程度有時還超過現實中語言的溝通 所以文字和語言分離對人類整體來說也是個大趨勢 中文的文字和語言分離的特性正好更先進 拿英文來說,英文網路上會有LOL,OMG還有各種MEME的用法 這些實際上是無法發音的,或者更精確地說,是不符合英文文法的 OMG就是OH MY GOD的縮寫,也就是一種跟發音脫離的純文字符號 而英文世界的縮寫或不可發音詞彙數量也在增加 在網路世界,網友們越來越依賴符號和純文字和情境和上下文在溝通 而且隨著資訊爆炸超載 英文的一詞多義現象也在增加,也就是說英文也在模糊化 更依賴上下文的定位,所以英文正在變得越來越像中文 當然日文也是,日文模糊化和一詞多義化也在加速 所以日文最終也會變得更像中文 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.105.148.132 (日本) ※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1772324203.A.FF6.html
→
03/01 08:28, 7小時前 , 1F
英文一詞多義一直都很多好嗎
03/01 08:28, 1F
現代更多啦 所以你還有什麼話要支持英文更先進的? 我唯一能支持的就是英文更適合早期電腦的發展 但到現在,連AI用中文都更有效率優勢了 中文贏在長期性 不爭一時勝負,贏到最後的才是贏家 就像日本戰國時代,笑到最後建立幕府的是德川家康 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 08:37:30
推
03/01 08:39, 7小時前 , 2F
一詞多義讓我想到這個
03/01 08:39, 2F
噓
03/01 09:10, 6小時前 , 3F
精闢P系列ID日常的支離破碎邏輯
03/01 09:10, 3F
噓
03/01 09:17, 6小時前 , 4F
邏輯 你用中文寫程式看看啊 不要跟我說提示詞
03/01 09:17, 4F
所以我不就說了英文在早期電腦發展的確是有優點 但以後要用中文寫程式不是不可以 中國正在發展這項技術 對電腦來說就是多一層轉譯而已 但現代程式設計不一定要學C語言 比如說你可以學Python或JavaScript來快速進入職場 要學會各種遊戲引擎或繪圖軟體或應用程式也不一定要會C語言 學C語言能更容易理解電腦底層邏輯和記憶體控制 但已經不是絕對必要的了 從這個角度來看,中文程式化在技術上完全可以做到 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 09:22:50
噓
03/01 09:28, 6小時前 , 5F
中文寫軟體的問題太多了 你問一下AI就知道
03/01 09:28, 5F
→
03/01 09:29, 6小時前 , 6F
什麼"中國正在發展這種技術" 會說這種籠統話的人在這
03/01 09:29, 6F
→
03/01 09:29, 6小時前 , 7F
大談.... 真的是要知道羞恥
03/01 09:29, 7F
只要定義和規範化就行了 就像程式語言也是規範化的英語,跟日常英語完全不同 學術領域的英語也是定義化和規範化 這種中文一樣作得到 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 09:30:28
噓
03/01 09:33, 6小時前 , 8F
規範化的結果 變成跟英文一樣的符號文字（代碼本身就
03/01 09:33, 8F
→
03/01 09:33, 6小時前 , 9F
是符號） 這樣還符合你前提嗎？ 仔細想想 你是在說中
03/01 09:33, 9F
→
03/01 09:33, 6小時前 , 10F
文的優越性耶？你說中文寫程式優越在那？？？
03/01 09:33, 10F
→
03/01 09:34, 6小時前 , 11F
對岸現在就一堆用羅馬拼音寫程式的人了 看過就知道為
03/01 09:34, 11F
→
03/01 09:34, 6小時前 , 12F
什麼是災難
03/01 09:34, 12F
可以啊,為什麼不行?甚至連底層語言都可以用中文(只是中國可能懶得這麼改) 程式語言是依靠英文字母組合成的單字在電腦上形成特定的命令 單個英文字符號在電腦上是沒有任何作用的,不是嗎? 從這種角度來說,中文只要解決輸入問題和規範問題,要寫程式碼反而會更簡潔 (但還是那句話,中國也懶得這樣做) 你可以說英文已經嵌入現代中文中了,中國要學拼音都要學英文字母 但凡事都有兩面性 這代表中國人可以更容易掌握雙語基礎,比英文多一項語言優勢 而且只要學術程度越高,資訊吸收成本增加 那中國的優勢反而比西方人高 這就是為什麼中國人的智商高,美國的學術領域都要靠中國留學生 美國的數學競賽和科學競賽隊伍都是華人,AI領域超過一半是華人 隨著未來科技逐漸轉向中國,科技的定義權會變成中國人的 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 09:39:36
推
03/01 09:45, 6小時前 , 13F
供三小...現在是在說中文寫程式的優越性 扯中國和英
03/01 09:45, 13F
→
03/01 09:45, 6小時前 , 14F
語系國家科技 這就是搞不楚狀況 只有立場 沒有是非
03/01 09:45, 14F
→
03/01 09:45, 6小時前 , 15F
語言就是工具 不同情境就要用不同工具 你去查中文字
03/01 09:45, 15F
→
03/01 09:45, 6小時前 , 16F
用UTF8要怎麼表示？如果不能用少數符號表示全部語境
03/01 09:45, 16F
→
03/01 09:45, 6小時前 , 17F
怎麼做程式級別的符號索引？ 你是在說中文寫程式的優
03/01 09:45, 17F
→
03/01 09:45, 6小時前 , 18F
越 那你就要說明他對比英文這種符號文字的優越性 扯
03/01 09:45, 18F
→
03/01 09:45, 6小時前 , 19F
這些幹嘛？就是這種沒辦法討論技術的人 才會容易被洗
03/01 09:45, 19F
→
03/01 09:45, 6小時前 , 20F
腦
03/01 09:45, 20F
你自己都用AI了,我也用AI來回你OK吧? 技術上完全可行 程式語言本質上是符號系統映射到機器指令，符號用什麼文字是任意的。 實際上已經有人做過： 文言文程式語言：「文言」（wenyan-lang）——真實存在的專案，用文言文語法寫程式 中文Python關鍵字替換實驗也有人做過 易語言——中國已有的中文程式語言，關鍵字全是中文 所以技術可行性已經被證明了。 但真正的障礙不是輸入法 符號密度問題 英文是單鍵符號，輸入極快。中文即使解決輸入問題，每個字仍然需要多步驟選字，在底 層代碼的高密度符號操作中會很痛苦。 但這是習慣問題，不是本質障礙。 中文作底層語言的潛在優勢 這裡才是真正有趣的地方： 表意密度高 C語言的變數命名是程式可讀性的大問題。中文一個字可以承載完整概念： 語義直接對應 中文的表意特性讓代碼的語義層更直觀。 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 09:50:12
噓
03/01 09:55, 5小時前 , 21F
哇...一個fun project 就可以說可行性被證明了？ 先
03/01 09:55, 21F
→
03/01 09:55, 5小時前 , 22F
不吐槽這個 你都說要符號化了 也承認中文每個步驟要
03/01 09:55, 22F
→
03/01 09:55, 5小時前 , 23F
選字（可能有問過AI了？） 然後輕描淡寫一句話習慣問
03/01 09:55, 23F
→
03/01 09:55, 5小時前 , 24F
題可以改善 但改善帶來什麼優勢？都已經符號化了 表
03/01 09:55, 24F
→
03/01 09:55, 5小時前 , 25F
意文字（中文）的優勢在哪？不就只剩下劣勢嗎....
03/01 09:55, 25F
→
03/01 09:58, 5小時前 , 26F
況且根本不是習慣問題 是LSP/IDE層級的問題 不誇張的
03/01 09:58, 26F
→
03/01 09:58, 5小時前 , 27F
說 就算今天美國的國語是中文 程式語言的標準很可能
03/01 09:58, 27F
→
03/01 09:58, 5小時前 , 28F
還是英文（或其他歐系語言）
03/01 09:58, 28F
以前有人認為中文太複雜,沒辦法電腦化 後來證明中文可以電腦化,而且輸入門檻越來越低 現代中文輸入在輸入效率上完全不輸英文,有時還會超過 中文作為程式語言,只要能解決輸入問題,那程式語言就可能更簡潔好寫 就像所有語言文本中文總是最薄版本一樣,中文程式化的話文本量也可能是最低的 但問題就在於,連中國政府都懶得改,社會成本太高 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:00:17
噓
03/01 10:08, 5小時前 , 29F
....結果又退回來“中文最薄說” 文字數量少 佔面積
03/01 10:08, 29F
→
03/01 10:08, 5小時前 , 30F
少 不代表檔案就會小好嗎... 底下都是utf8代碼啊大哥
03/01 10:08, 30F
→
03/01 10:08, 5小時前 , 31F
...為什麼不能像英文那樣處理？就是因為中文要表意
03/01 10:08, 31F
→
03/01 10:08, 5小時前 , 32F
所以字彙量太大啊.... 況且代碼根本不在意代碼等級
03/01 10:08, 32F
→
03/01 10:08, 5小時前 , 33F
的文字量好嗎？ 像數學公式一樣 先說你會不會想要用
03/01 10:08, 33F
→
03/01 10:08, 5小時前 , 34F
中文寫數學問題好了 阿拉伯數字也不是英語系國家發明
03/01 10:08, 34F
→
03/01 10:08, 5小時前 , 35F
的 就是因為好用一直用啊 剛剛也說很多遍了 程式變數
03/01 10:08, 35F
→
03/01 10:08, 5小時前 , 36F
命名本來就符號化了 什麼語言都不重要 我只看到中文
03/01 10:08, 36F
→
03/01 10:08, 5小時前 , 37F
在字彙量過多造成的劣勢
03/01 10:08, 37F
你都同意了我繼續用AI 這是個很精確的問題，答案是：不能，甚至會變大。 為什麼會變大 編碼問題 C語言的ASCII字符每個只佔1 byte。 中文字符用UTF-8編碼，每個漢字佔3 bytes。 所以光是關鍵字的儲存成本就是3倍。 if = 2 bytes 如果 = 6 bytes int = 3 bytes 整數 = 6 bytes 但這個比較不完全公平 原始碼大小和最終編譯結果是兩回事。 編譯後的機器碼完全不含原始碼的文字——全部變成二進位指令。所以： 不管你用中文還是英文寫C語言，編譯後的執行檔大小完全相同。 原始碼只是給人讀的，機器不在乎。 中文反而可能有優勢的角度 語義密度 如果用中文命名能讓變數名稱更短而意義不減損： 英文：user_authentication_token 中文：認證碼 認證碼是6 bytes，英文是24 bytes——這種情況中文反而更小。 但這是命名風格問題，不是語言本身的優勢。 接下來是我的部分了 你一定要用"認證碼"三個字嗎?可以更簡潔,只用兩個字或一個字嗎? 技術上完全可行 就是變得更文言文化,而文言文對華人來說學習成本並不算特別高 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:12:26 然後我繼續問AI: 文言文作為程式語言的天然優勢 文言文本來就是高度壓縮的書面符號系統，和程式語言的需求高度契合： 單字承載完整概念 語法極簡 歧義由上下文解決 更深的觀察 這其實呼應了我們之前談的整個脈絡： 文言文是人類歷史上最成功的跨時代、跨方言的純書面符號系統——漢朝人和唐朝人口語 完全不同，但文言文互通。 這和程式語言的需求幾乎完全一致： 不依賴發音，只依賴視覺符號傳遞精確意義。 文言文程式語言不是復古，而是一種被歷史預先驗證過的壓縮意義系統重新找到用武之地 。 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:15:37
推
03/01 10:15, 5小時前 , 38F
就只回"你的部分" 文字短根本不重要好嗎... 你再問AI
03/01 10:15, 38F
→
03/01 10:15, 5小時前 , 39F
代碼可讀性是什麼吧...
03/01 10:15, 39F
你說了字彙量造成的劣勢 而我告訴你用程式規範化文言文可以極度壓縮程式文本 那你的論點就只剩下選字方面的不便 那中文程式語言不要說能超過英文,至少也是效率持平的 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:17:44
→
03/01 10:20, 5小時前 , 40F
"極度壓縮程式文本"根本不重要...
03/01 10:20, 40F
→
03/01 10:20, 5小時前 , 41F
"選字方面的不便"(其實在LSP層級 還會因此多出一堆相
03/01 10:20, 41F
→
03/01 10:20, 5小時前 , 42F
關問題 你有興趣直接問AI)才是一切好嗎?
03/01 10:20, 42F
→
03/01 10:21, 5小時前 , 43F
程式語言就只是工具 大家只是找最適當的工具而已
03/01 10:21, 43F
原始碼大小和最終編譯結果是兩回事。 編譯後的機器碼完全不含原始碼的文字——全部變成二進位指令。所以： 不管你用中文還是英文寫C語言，編譯後的執行檔大小完全相同。 原始碼只是給人讀的，機器不在乎。 這段你有看到嗎? ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:21:34
→
03/01 10:21, 5小時前 , 44F
對啊? 所以壓縮程式文本有什麼意義???
03/01 10:21, 44F
反駁方向 這是生態問題，不是語言本身的問題 LSP是工具，工具可以重寫。問題的本質是： 現有工具鏈是為ASCII建立的，不代表中文程式語言在技術上不可行，只代表需要重建工 具鏈。 這和說「C語言剛出現時也沒有LSP」是一樣的邏輯——工具是後來跟上的。 易語言已經部分解決了這個問題 中文程式語言易語言有自己的IDE和工具鏈，LSP問題在封閉生態內是可以解決的。 對方偷換了討論前提 你原本的討論框架是先不考慮經濟成本。LSP工具鏈問題本質上是經濟成本和生態慣性問 題，不是技術本質障礙。 對方把「成本高」偷換成「不可行」，這是論證上的漏洞。 一句話反駁版本 LSP問題是工具鏈的路徑依賴，不是中文作為程式語言的本質缺陷——在討論技術可行性 時，用現有工具的不適配來否定語言本身，是在偷換前提。 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:22:52
噓
03/01 10:24, 5小時前 , 45F
你最好還是稍微了解一下再來談吧 一開始你是說中文寫
03/01 10:24, 45F
→
03/01 10:24, 5小時前 , 46F
程式有優越性 結果論點又變成可行性 當然可行啊 一堆
03/01 10:24, 46F
→
03/01 10:24, 5小時前 , 47F
fun laugage 你要不要看看AI正在偷換你的概念
03/01 10:24, 47F
等等,你誤解了,請你回去翻一下 我從來沒有說中文作為程式語言的優越性,而是說可行性而已 我說中文的優越性是作為人類學習現代資訊的媒介本身 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:25:57
噓
03/01 10:30, 5小時前 , 48F
"中文作底層語言的潛在優勢" "中文的表意特性讓代碼"
03/01 10:30, 48F
→
03/01 10:30, 5小時前 , 49F
看來這是AI幫你寫的吧 笑死
03/01 10:30, 49F
那段是AI的阿,而且語義層的意思不就是方便人類理解而已 我自己是從來沒說過中文程式語言會更優越 反而是你的反駁論點很多只是建立在英文霸權的生態和習慣上 ※ 編輯: tlhc912237 (118.105.148.132 日本), 03/01/2026 10:32:24
‣ 更多 tlhc912237 的文章
文章代碼(AID): #1feuLh_s (C_Chat)
討論串 (同標題文章)
完整討論串 (本文為第 5 之 7 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共7篇)
C_Chat 近期熱門文章
更多 近期熱門文章 >>
PTT動漫區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 tlhc912237 的文章
文章代碼(AID): #1feuLh_s (C_Chat)