中文編程的路該怎麼走?

說起來,我關注程序和編程,是從小學時姑姑家買了電腦,我把玩後開始感興趣的,

然後是初中畢業,想找到一條生存路,開始研究程序世界,但遇上了互聯網鋪開和娛樂至上年代,

後面讀了個大專學軟件工程,但屁用沒有,老師完全不教編程相關,竟然還教毛概,大數,大語等半點關系都沒有的,

還要考試,我那會兒就開始反思中國的教育是不是出問題了,

之後,自然地,畢業即失業,一直打散工,直到16年開始關注中文編程,一直找了這麼多年,

尋覓過很多道路,其中也遇到過一些道友,發現都無法精準命中中文編程的痛點,即中文編程的出路在哪裡,

時至今日,中文編程尚處于萌芽狀态,從吳濤的易語言到現在,可以看出,中文編程既沒有PL理論,也沒有建立出什麼實際的程序生态和編程生态,更别提基于共識起草标準了,所以中文編程這個事業,還是一事無成的零蛋,

程序的本質就是,從零憑空構造一套系統,看起來脫離實際,其實它緊密圍繞世界的實際邏輯建立,即策略、模式匹配、算法等概念描述的一個抽象對象,

我觀中文編程的現狀,得出一些膚淺的分析結論;

它從上到下(頂到底),或從下到上,都行不通,因為這些已經是西方軟件工程建立了半個多世紀的壁壘,

其體系和生态已經非常龐大繁雜,所以現在入程序行業的人,一般都是加入他們,

這些人秉持的理念是打不過就加入,而非獨立自主搞自己的,畢竟像倪光南和吳濤這樣有骨梁的在一個群體裡始終是少數,

所謂從上到下,就是從應用層到指令系統,應用層就是生态,生态每天都在産生海量的庫,

無論是漢化它還是使用它(這個使用是指生産者實施者)都是南轅北轍,隻會疲于奔命地跟着西方的屁股跑,

而從下到上,看似簡單,實則壁壘高到難以想象,西方人在最基本的東西裡穿插了技術牆,

比如指令系統,就是指令集,我用的是x86,我想找到指令的機器碼,我發現它根本沒有固定的0101構成的機器指令,

因為它是CISC,所以它的指令是動态編碼的,我想做一個x86的彙編器,我需要看懂它的說明書,

還要會一門靜态編譯性語言,而這兩樣對一個非專業的普通人來說就像天書,

其說明書,要看英文是基本的,其技術性的詞彙和描述,和帶有文法陷阱(俚語,慣用口語)的句子和縮寫,

是壁壘和技術牆的雙重壓制,而靜态編譯性的語言一樣有這個問題,更别提破解靜态編譯語言的編譯器,

比登天還難,這一系列就像三體裡的質子,從最基本的規則中鎖死我們在這個領域的發展,

拟人比喻就是,削掉你的頭和四肢和五髒六腑,隻留十個手指和血管連着,讓你隻用手指為西方的軟件工程生态添磚加瓦,

通過血管輸送養分供養西方程序生态,現在加入的那幫人就在幹這個事,并且他們還有優越感,

當然,現在有開源的RISC-V可供選擇,它有固定的0101機器指令,寫彙編器應該沒那麼難了,

但我沒有基于它的CPU和整機,所以我無從下手,

經過上述分析,和平日裡的反思,我找到的路就是虛拟機這條路,

虛拟機指語言虛拟機,不局限于某種指令系統和處理器架構,也不局限于某個操作系統,

因為它是一台虛拟的機器,是對圖靈機或馮氏結構的虛拟化,用軟件和程序來模拟,

當前隻有這條路可走,它能破解從上到下還是從下到上的問題,jvm字節碼和llvm中間碼就是這種産物,

我以前沒注意到這條路的可行性,但現在我發現虛拟化才是中文編程真正可以實現和走的路,

有人要說龍芯,但龍芯的指令系統和處理器架構,一是繼承自西方體系的指令集和設計理論,二是為了接西方體系的軌,

而非真正的獨立自主,它沒有真正意義上的從零的彙編器和編譯器,大家可以去看它的官方文檔,

龍芯的目的還是為了供養西方軟件生态,因為他們想從西方生态裡分一杯羹,所以龍芯從源頭的路就是歪的,

所以中文編程想要擁有自己的硬件生态體系,那就必須要完全從零設計指令系統,和由此而生的PL理論和彙編标準,

以及,适應這套指令系統的電路,IC生态,等等,

當然,我們現在熱衷中文編程的道友,不奢望硬件生态,因為那實在可望不可及,

所以我們隻能搞搞中文編程的軟件生态體系,通過語言虛拟機來構造中文漢字程序生态這個上層建築,

經過這麼多年的熱衷探索,中文編碼标準在馮氏結構裡是一個全面性被打壓的問題,

馮氏結構有5大部件,分别是[運算器、存儲器、控制器、輸入、輸出],這不單單是硬件電路使用了這些概念,

馮氏結構是一種理論,它在軟件和程序裡也是可以應用的,編程語言的功能清單裡,不但包含了基于5大概念構造的功能,

比如數組,變量,流程控制. 還有基于這基本概念構造的複合功能,比如結構體,函數.

還有文件系統也有5大概念的本質,輸入法也一樣,例子太多不列舉,

如果光是尋覓編程語言的編碼,其實是南轅北轍,真正應該研究的是馮氏結構概念實例化後的編碼和指令系統的字符編碼,

方能深入破解中文編程編碼标準的根源,

中文字符編碼不單單隻局限于輸入和輸出,大家明白吧,

基于上述分析,若要搞中文編程的語言虛拟機,第一步是設計基于中文漢字的指令系統,

用漢化的方式寫虛拟機是基本要求,即标識符就得是中文漢字,設計虛拟機所用的馮氏結構概念得用中文漢字編碼,

這樣就可以從源頭用中文漢字封裝馮氏結構概念為基本編程組件,

那麼用這樣的語言虛拟機建立的上層建築,比如彙編器,PL理論,編譯器,輸入法等等基礎設施,才能完全是基于中文漢字的,

也就不會遇到編碼問題,

說一個歧視性的問題,UTF8是對Unicode的再編碼,當它編碼漢字的時候,大多是用2-3個字節來存儲漢字的,

每個字節8位二進制(一個字節),也就是說存儲一個漢字要有16位-24位二進制,大家考慮下,16位甚至24位二進制可以代表多少個狀态了?

常用漢字3000-5000個,也就是說最多隻需5000個狀态,所以要存儲漢字12位-16位是完全夠了,

甚至康熙字典都能全部存儲下來,而UTF8是為了适應拉丁字母的排位而設計的,字母在UTF8碼表裡享有第一優先級,

字母大多是用8位二進制編碼的(一個字節),所以UTF8編碼算法是未滿256個狀态之前存儲字母,超過256個狀态的字符,

就用16位甚至24位二進制來編碼存儲,故意增高非拉丁字符的存儲成本,讓非歐羅巴文明的種族覺得自己使用的文字低人一等,

而UTF8是現在軟件程序互聯網打印機反正就是信息傳輸、存儲、處理的事實标準,

大家仔細想吧,為啥不是UTF16流行或幹脆Unicode本身流行?為啥非得定義8位二進制 = 一個字節?一切都是為了西方優先.

要搞中文編程,其實首先應該解決中文編碼的問題,然而卻沒有任何人反思這一點,

當然,UTF8也是可以用,就是成本和代價高了億點,自然就由大家來全體承擔了,

還有一個,PL理論不是非得用龍書虎書鲸書那一套編譯理論,并且,除了圖靈機以外還有一大把計算理論,

但是當你打開搜索編譯器相關的時候,出來的幾乎全都是"詞法分析""語法分析""代碼生成"那一套,為啥?

因為被降維打擊了呀,因為"加入他們"的那部分人在十多年前就開始帶節奏了,典型的比如輪子哥,

中文編程的生路難走至極,但走出來就可以日月換,

生态的問題不是一個人能解決的,打破封印需要破解者,而非歸順者,

-----------------------------------

我終于明白了為啥中文編程這麼難,受到西方施加的壁壘鉗制,昂撒人果然是專門搞了一個技術牆來擋住我們的發展,

最近在Windows上練習cpp的時候,我發現即便是用支持UTF8的終端來輸出,一樣顯示亂碼,

然後我又專門測試了char 和 string 兩種數據類型對中文漢字的支持,

結果是要不就顯示亂碼要不就是胡亂的圖形塊,即便是加上小u大U也無濟于事,一樣的結果,

由此我得出結論是編譯器的問題,看來根本問題是編譯器不支持Unicode,

源代碼在編譯器裡處理的時候,從本源上不支持Unicode,對UTF8的支持也是半杯水半成品,

我發現8位二進制 = 1字節與char類型還有ASCII是深度綁定了的,在我查閱了cpp的标準文檔以後确定了這點,

原來編程這個事從根源上就對中文漢字排斥,編譯器有排他的内因,

聯想到目前的編譯器大多用c或cpp進行開發,例如gcc和llvm,私有的更不必說,

再加上Windows的cmd幾乎無法與編譯器對非拉丁文輸出和諧相處,

而大多數别的C語族編程語言都是基于gcc和llvm或用c和cpp開發,我發現這是把死循環焊死了屬于是,

又聯想到本國Windows的市占率,昂撒人的野心果然不是蓋的,

不過,Linux我還沒測試過,據說Linux早就完全從最底層支持了UTF8,希望有人能測試下,

不知道基于c和cpp開發的gcc和llvm能否在Linux上無差别支持中文漢字,

靜态編譯型語言除了c和cpp,現在也就rust了,我倒是測試過rust,畢竟出生得晚,确實完全支持UTF8,

帶有中文漢字的源碼編譯後運行沒有任何亂碼,蘋果系的編譯器和系統沒機會測試,不曉得,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!