canonical

    我在前面的文章中列舉了大量物理學相關的例子來試圖說明采用物理視角的必要性,但是可能因為物理事實大家不熟悉,結果直接被無視了. 在本文中我想有必要舉一個軟件領域的例子。只是在實際思考的過程中,我主要還是基于物理概念進行推理.
   
    首先我所謂“現在的通用語言”，它并不意指“現在至未來所有通用語言之合集”，而是指“目前正在被使用的某一種通用語言”，這種差別便體現了我所強調的不同的價值觀和不同的視角。不是一種覆蓋一切的全稱判斷，而是在特定物理約束下的物理實體。
   
    現在無論我們設計什么大型系統，一般總是要優先考慮微內核設計。但是很顯然，如果我們的編程控制能力極強（強大到不現實的地步），我們可以把所有的代碼實現為一個大的整體。一個整體的好處是勿用質疑的，否則Linux Torvalds就不會有信心和Tanenbaum PK。但即使是Linux, 隨著系統越來越龐大，在內核中也補充了很多模塊管理策略。我并不把這種情況看作是一種現在技術能力不到位所造成的結果，而是把它看作是在現實的物理約束下所促成的一種必然的選擇。
   
    按照類似的邏輯，我認為在通用語言層面不應該導入越來越多的特征，實際上也不可能把所有可能的結構方式都內置在語言中（這種不可能不是數學意義上的不可能）。這會破壞一種語言的純潔性，使得它極難維護和發展。為了擴大通用語言的有效應用范圍，一種顯然的方式是在語言中定義一些支持結構再次抽象的機制，通過可插拔的方式實現與domain相關的知識的融合。ruby這樣的語言提供了大量的元編程機制, Witrix平臺中tpl模板語言也發展了一系列編譯期結構構造技術, 但是顯然它們都不能說是結構抽象技術的終極形態. 目前我對所有通用語言所提供的結構抽象和結構組裝能力都是不滿意的,因此在Witrix中發展了一些領域特定的結構融合手段.例如根據"繼承"關系的結構詮釋(繼承可以看作是兩個一維集合之間的覆蓋關系), 我們擴展了extends的結構操作方式, 定義了廣義的extends算子. 這些特定的結構關系目前在領域特定的BizFlow語言中體現, 它們在通用語言中是難以想象的, 而把它們放置在通用的語言中也是不合適的(這種復雜的結構融合操作如果不能結合領域知識進行直觀的理解, 必將導向一種思維的混亂). 這就是我所謂"現在的通用語言無法有效承載Domain Specific Structure"的含義. 這種說法其實類似于"集合論是無法包容所有數學結構的". 我們在集合論中只研究最普遍的關系,而特定的結構在特定的學科中研究.
   
    關于ErLang的例子, 我的原意是用來說明結構問題是獨立的,它是和具體語言無關的.即基于消息傳遞發生數據關聯的超輕量級進程模型這一結構不是和ErLang語言綁定的. 為此我特意加了一段說明:"這里不是要證明某種語言中無法描述這些結構，而是說結構是客觀存在的，它并不是要在基礎語言層面得到充分解決的". 即使在語言層面我們并不解決這個結構問題, 它仍然客觀存在著,我們仍然可以用其他的技術手段去定義,去解決. 解決了這個結構問題就必然會帶給我們價值,而無論我們使用何種實現語言.

    "什么原因，什么樣的約束條件,導致了現在的通用語言是無法有效承載消息傳遞發生數據關聯的超輕量級進程模型". 這一命題并不是我原文中論點的合理推論.我并不是要說某一種特定的領域結構無法在一種特定的通用語言中得到支持.而是說如果我們認為一種通用語言是比較穩定的,則它一般選擇只內置一些通用的不帶有領域特定含義的概念. 而缺乏領域知識,或者說因為通用語言故意的摒棄領域依賴, 它在處理領域相關的問題的時候并不是有效的.這種有效性不是數學含義上的,而是可以進行物理度量的. 現在也有很多人認為ErLang并不是真正的通用語言,它是針對通信領域進行了特定結構調整的, 是內置了領域特定結構的. 而目前在ErLang上建立GUI的努力也并不算是成功.
   
    在前文中我舉了一個例子試圖說明:"在限定的物理約束下，我們的選擇范圍會大大縮小". "比如說我現在有無窮多種方式從北京跑到上海，但是如果限定只允許用1升汽油，那么我們的選擇就近乎于0". 這里并不是要說明加上物理約束之后,我們便沒有任何選擇了.而是說物理約束對無窮多的可能方式起了限定選擇的作用, 它最終造成我們在具體的物理場景下可能只有非常有限的選擇. 例如現在允許用100升汽油, 有多少種運輸方式可以滿足我們的要求? 如果允許1000升呢? 但是如果不考慮所有物理約束, 我們是否能夠證明說: 飛機和拖拉機的運輸能力是完全一致的, 因為它們都能從北京開到上海.

    我的觀點是結構問題是獨立存在的,它具有自身的價值, 研究它也需要建立特定的價值觀. 一個結構可以體現為語言上的某種語法特征, 也可以通過框架等實現, 或者表現為某種設計模式,某種編程技巧. 我們在思考結構問題的時候并不是從特定語言的機制出發的, 當語言不直接支持的時候我們可以發展特定的實現技術支持它. 在未來的日子里某個結構可能被證明具有普適的價值,它會被吸收到某個通用語言中成為所有程序的支撐結構, 但是更多的結構永遠都不會進入通用語言, 而是居留在某個特定的領域. 通用語言的發展并不是完全基于抽象的數學分析而進行的, 它可以從更加豐富的物理世界中吸取營養. 當一種結構進入通用語言的時候, 它所帶來的絕對不只是一組數量關系,而是同時帶來一系列經過實踐檢驗的物理詮釋.

    我所謂的領域并不是指業務領域, 而是結構領域, 一個可以定義特定結構的物理場景. 一個特定的結構仍然可以支撐著任意多的具體應用. 例如CRUD操作可以作為數據管理模型. BizFlow作為界面和單實體的交互模型.

    函數式語言為我們提供了一種具體的技術工具, 但是在現實的開發中, 為了有效的處理結構問題, 顯然我們需要多種視角的組合, 而不是把所有可想見的圖景都純化為函數. 我們對世界的體驗是多樣化的. 這就是我所謂"世界比函數的集合要復雜"的含義.