canonical

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

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

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

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

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