結構的獨立性

設計考慮的是最終需要什麼，最終我們要提供的調用接口是什麼，我們所直接需要的某個有價值的，直接存在的，直接可以接觸的結構是什麼，而不是它所依據的原理是什麼，不是它的具體構造過程或者構造方法是什麼。比如說我們在程序中完全不需要內置Map這一結構，因爲它可以通過列表等結構組合構建出來，但是很顯然，Map這一概念的直接存在對我們來說是方便的，是經濟的，是有效的。我們在思考的時候並不需要考慮它是採用List實現還是採用Set實現，或者任何它本身的構造結構。這一概念在我們的思想中成爲某種原子化的東西。

那麼，我們到底需要構建哪些概念，才能夠最方便的基於這些概念應對萬千應用系統的開發呢。 這是我們需要在結構空間作出探索的。 這裏的思維方向不是把系統推向某種純粹化，某種極致的簡單化，而是讓它更加物理化，揭示出更多的層次，更加關切在物理約束情況下如何實現靈活性的最大化。一種概念在物理上如果被證明能夠在很多場景下成爲不變的基元，則它便是有價值的，是可以進行物理詮釋的。

很多人習慣於接受語言存在的現實，接受設計後的結果，但是作爲程序語言設計者，他們又是如何工作的？他們是否真的是從純粹的數學關係推演得到所有的語法特徵，還是他們預先已經在心中設定了應該出現的語法特徵，然後去尋找它的數學表達，只是藉此清除思維中潛在存在的矛盾性呢？

語言中存在的所有特徵是經過全局考慮的，是清除了所有概念的矛盾衝突的。但是在現實中，我們偶然構造的結構卻可能是侷限於當下的信息構造的，因此它們相會的時候，可能會出現不協調，可能會出現結構障礙。例如同樣是關閉操作，有些人命名爲close, 另一些人命名爲destroy. 可能一個具有額外參數，另外一個沒有。這裏可能需要一種adaptor接口的封裝，也可能使用ruby那種method-missing的動態判斷。對於更加錯綜複雜的結構問題，其解決方案就不是那麼顯然的了，但這並不意味着我們無辦法可想。究竟設計何種結構邊界才能最小化結構融合時所要付出的代價呢？結構被識別並表徵出來以後，是否允許它在一定範圍內有所變形？在變形中我們需要保持的拓撲不變量是什麼？結構動態調整的時候，我們是否需要定義調整的物理代價，是否能夠定義某種動力學？

我所闡述的只是在計算機理論中從數學視角向物理視角的轉換，它不是必然給你某種超越當下的能力，而是提供一種不同的眼光看待所有的一切。視角變換後，我們發現了一些新的命題，而在原先的視角下在我們的話語體系中原本是無法表達這些命題的。串行程序假設了只有1顆CPU, 而函數式語言假設了可以有無限多個CPU, 你不覺得1至無窮之間缺點什麼嗎。我們可以創造一些東西把1至無窮之間的空白補齊，概念空間是連續的。