canonical

       負數沒有直接的幾何意義，因此它被認為是對應于不存在的事物。而按照古希臘的邏輯，不存在的事物是不可能存在的，因而也就是無法被理解的，更不可能參與到 推理過程中，因此是無意義的，無法被定義的， 因此它是不存在的。中國人注重的是運算的合理性，而不是數的真理性，大概在公元前400年左右就創造了負數和零的概念。而在西方直到公元7世紀（唐代）的 一本印度人的著作中才出現負數，它被用來表示負債。西方人沒有能夠創造負數，他們對負數的接受更遲至15世紀左右。這件事實在一定程度上說明了存在某種深 刻的困難阻礙我們理解負數概念。
       在引入負數之前，3x^2 + 8 = 4x 和  3x^2 + 4x + 8 = 0 這兩個方程的結構是完全不同的，它們需要不同的求解技術，因此也就不可能利用符號抽象出 a x^2 + b x + c = 0。引入負數才使得我們能夠以統一的方式提出問題，并研究通用的求解技術。
      群論(Group Theory)是對結構進行抽象研究的數學分支。群的定義包括四條規則
1.    元素之間的運算滿足結合律 (a * b) * c = a * (b * c)
2.    元素之間的運算封閉，即 a * b 仍然屬于該群
3.    存在單位元，即對所有a, a * e = e*a = a
4.    每個元素存在對應的逆元，a * a^-1= e
      逆運算是非常重要的結構要求，逆元是對負數的一種抽象推廣。如果沒有逆元，則只能構成半群(semi-group)，它的性質要少很多。

      目前軟件設計中所有的原則都指向組裝過程，從無到有，層層累進。構件組裝的隱喻中所包含的圖像是操縱實際可見的積木，是缺少逆元概念的。

      考察一個簡單的例子，假設需要的產品是三角形內部挖去一個五邊形的剩余部分。有三種生產策略：
1.    對最終需要的產品形態進行三角剖分，使用8個小三角形拼接出來。這種方式比較繁瑣，而且最后粘接工序的可靠性和精確性值得懷疑。
2.    拿到一個真實的三角形，然后用刀在內部挖出一個五邊形的洞。這種方式需要消耗一定的人工，而且也很難保證五邊形的精確性，即使我們曾經精確的生產過其他五角形和三角形。實際上一般情況下我們是逐步銼出一個五邊形的，并沒有充分利用到五邊形的對稱性。
3.    在概念空間中做一個抽象計算  (-五邊形) + (三角形) = 所需產品
如果我們能夠生產一種負的五邊形和一種正的三角形，則可以立刻得到最終的產品。

 
在軟件開發的實踐中，我們目前多數采用的是兩種方式：
1.    采用可視化設計工具通過拖拽操作開發出完整的界面和后臺
2.    拷貝一些已有的代碼，刪除掉不需要的部分，增加一些新的實現，也可能對已有實現做一些不兼容的修正。

在第二種方式中
           新結構的構造 = 已有結構 + 軟件之外的由人執行的一個剪裁過程
這個剪裁過程表現為一個時間序列。如果我們對原有結構進行了調整，則需要重新關聯一個時間序列，而此時間序列并不會自動重播。為了壓縮以時間為度量單位的 生產成本，我們必須減少對時間序列的依賴。在時間序列中展開的一個構造過程可以被轉化為一個高維設計空間中的一種更加豐富的構造原理，我們最終的觀測可以 看作是設計空間向物理空間的一個投影（想象一束光打下來）。這種方式更容易保證程序的正確性。
          時間序列 --[原理轉化]--> 空間關系

    這樣我們就可以使用第三種生產策略：利用構造原理進行抽象計算。如果我們只盯著產品的最終形態看，只是想著怎么把它像搭積木一樣搭建出來，就不可能識別出 系統結構本身所蘊含的對稱性。如果我們發現了系統內蘊的結構特征，但是卻只能通過構造過程中的行動序列來追隨它，同樣無法實現有效的工作復用。同時因為這 個行動序列一般處于系統規則約束之外，完全由人的自覺來保障，因此很難保證它的正確性。現實世界的規范要求并不是模型本身所必須滿足的，只要我們能夠創造 新的結構原理，在概念空間中我們就可以擁有更多的自由。現在業內鼓吹的軟件構造原理多半是參照物理世界中生產具體物質產品的生產工序，卻沒有真正把握信息的抽象本質。掌握規則，制訂規則，才是信息空間中的游戲規則。

    物理學中最重要的分析學思想之一是微擾論(Perturbation). 針對一個復雜的物理現象，首先建立一個全局的規范的模型，然后考慮各種微擾條件對原有模型的影響。在小擾動情況下，模型的變化部分往往可以被線性化，被局 域化，因而問題得到簡化。微擾分析得到的解依賴于全局模型的解而存在，因而這是一種主從關系的分解方式。但是如果主體模型是我們已經熟知的物理現象，則我 們關注的重點可以全部放在擾動解上，認為所有特定的物理規律都體現在擾動解中。如果微擾分析得到的物理元素足夠豐富，則微擾模型本身可以成為獨立的研究對 象，在其中我們同樣可以發現某種普適的結構規律。
    考察如下的構造過程
       X = a + b + c
       Y = a + b + d = (a + b + c) - c + d = X - c + d
    對于數學而言，上述的推導是等價的，但是對于物理學而言，Y = a + b + d 和  Y = X - c + d是有著本質不同的。第一種方式要求打破原先X的構造，而重新的組裝其實是有成本的，特別是在X本身非常復雜的情況下。典型的，如果X是經過測試的功能， 重新組裝后原先由測試保障的概念邊界被打破。
         我們可以從Y = X + dX抽象出擾動模型  dX = - c + d
主從分解模式自然的導出逆元概念。

      如果沒有逆元，我們必然需要分解。但是如果發掘了背景這一概念，在逆元運算下，對背景不是分解讓其成為可見的部分，而是采用追加的，增刪的方法對背景結構 進行修正，則我們有可能在沒有完整背景知識的情況下，獨立的理解局部變化的結構。即背景是透明的，知識成為局部的。在Witrix平臺中，BizFlow + DaoWebAction + StdPage 才構成完整的程序模型，BizFlow其實是對標準模型的差異描述，但是它可以被單獨的理解。如果我們從接觸程序開始就接受BizFlow, 就可能完全不需要了解數據庫訪問和前臺界面渲染的知識。我們并不是通過在DaoWebAction中設定各種可預見的調用形式，而是在BizFlow中通 過類似AOP的操作方式直接對標準模型進行修正。這種修正中一個很重要的部分就是刪除標準模型中缺省提供的功能。
     WebMVC之前世今生 http://canonical.javaeye.com/blog/163196
     Witrix架構分析 http://canonical.javaeye.com/blog/126467


      變化的部分構成獨立于原始模型的新的模型，它的結構關系是完備的，可以獨立的理解。在原始模型崩潰的情況下，它仍然可能保持有效性。
      從物理學的角度看，我們所觀測到的一切物理現象，都是某種物理作用的結果，也就是物質結構相對于背景狀況的一種偏離。我們只可能觀測到變化的部分，因此我們對世界的認識其實只是世界的擾動模型而已，世界的本體不屬于科學研究的范疇。

    軟件技術的發展是一個結構化不斷加深的過程，我們逐漸擁有了越來越豐富的結構識別, 表達和處理手段。在這一方向上, 組件技術最終取得了巨大的商業成功。但是區分同時也就意味著隔閡。面向對象技術最基礎的概念在于 O = C(O), 對象的復合(Composition)仍然是對象.  然而在越來越復雜的軟件生態環境中,這一圖景實現的可能性被大大的壓縮. 面對層層封裝造成的形態各異的表達方式, 不同來源, 不同目標, 不同運行環境下的信息的交互變得越來越困難。我們逐漸喪失了概念上的簡潔性, 也喪失了數學世界中的那種穿透一切的統一的力量. 所謂SOA（Serivce Oriented Architecture)技術試圖通過補充更多的環境信息，放棄狀態關聯，暴露元知識等方式來突破現有的困境。 http://canonical.javaeye.com/blog/33803 這其中一項關鍵的技術抉擇是基于文本格式進行信息表達。

      在過去10年中Web技術取得了空前的成功，它造就了互聯網這一世界上最大的分布式集成應用。SOA從某種程度上說是對這一事實在技術層面上的反思。基于 文本傳遞的web技術所表現出來的開放性，可理解性和可觀測性，與封閉的，難以直接解讀的，必須擁有大量相關知識才能正確操作的二進制結構相比，這本身就 是革命性的創新。不需要特殊的工具就可以非常輕易的察看到網頁程序的輸入輸出，所有交互過程都處在完全透明的檢查下，各種不曾事先規劃的文本處理手段都可 以參與到web創建的過程中。隨著速度，存儲不再是我們考慮的首要問題，文本化作為一種技術趨勢逐漸變得明確起來。但是任何一種技術思想的成功或失敗都不 可能是因為某種單一的原因所造成的，因此有必要對文本化的技術價值做更加細致的剖析。
  
   1. 文本化是一定程度上的去結構化，但是通過這種方式我們獲得了對程序結構的更強的控制力。無論我們所關心的文本片斷層層嵌套在大段文本的哪個部分，我們都可 以通過text.indexOf(subStr)來實現定位，通過text.replace(oldStr,newStr)實現變換。而在組件系統中，我 們只有通過某種預定的遍歷方式逐步遞歸才有可能訪問到組件內部的組成對象。如果某個組件不按照規范實現或者規范中缺少明確的設定，則這一信息關聯鏈條將會 斷裂。在一些組件系統中，甚至沒有規定一種統一的遍歷方式，則我們根本無法定義出通用的大范圍的結構定位/變換手段。即使是在設計精良的組件框架中，受限 制于組件的封裝性要求，我們也不可能訪問到全部的信息。當我們以組件設計者意料之外的方式使用這些組件的時候，就會遇到重重障礙。即使所需的只是微小的局 部調整，因為無法觸及到需要修改的部分，我們也可能被迫放棄整個組件。
  
   2. 文本是普適的信道。各種操作系統，各種程序語言所具有的最基本的能力就是文本處理能力，對于文本格式的約定是最容易達成共識的。雖然對于機器而言，理解基 于地址定位的二進制數字可能更加直接，但是所有的應用程序都是由人來負責編制，調試，部署，維護的，如果人可以不借助特殊的工具就可以明確了解到系統內發 生的過程，則系統的構建和維護成本就會大幅下降。
  
   3. 文本表述形式上的冗余性增強了系統的概念穩定性和局部可理解性。在二進制格式中，經常出現的是根據相對地址定位，這要求我們完整理解整個二進制結構，才能 夠逐步定位到局部數據塊。同時，二進制格式中也經常使用一些外部的信息，例如某個位置處的數據為整型，占用四個字節等。這樣的信息可能只能在文檔說明里查 到，而在數據體中沒有任何的體現，這限制了獨立的理解可能性。與此相反，文本格式經常是自說明式的，例如width:3.5px, 這提高了系統的可理解性，特別是局部可理解性。即使我們對系統只具有很少的知識，一般也能根據數據周圍的相關信息進行局部操作。一般很容易就能夠定位到特 殊的局部數據區，安全的跳過眾多未知的或者不被關心的結構. 一個程序新手也可以在很短時間內靠著連蒙帶猜, 實現xml格式的word文件中的書簽替換功能,而要搞清楚word的二進制格式,并獨立編制出正確的替換功能,顯然就不是一兩周的工作量可以解決的了. 這其中, 可理解性的差異是存在著數量級上的鴻溝的.
  
   4. xml這種半結構化的文本格式規范的興起, 以通用的方式為文本描述引入了基本的形式約束, 實現了結構表達的均一性. C語言中的宏(Macro)本質上就是一種文本替換技術,它的威力在于沒有預定義的語義, 因此可以超越其他語法成分, 破除現有語法無法跨越的限制. 但是它的危險性在于缺乏與其能力相適應的形式約束, 難以控制. 而在xml格式規范下, 不同語義, 不同抽象層面的節點可以共存在同一個形式體系中, 可以用通用的方式進行定位,校驗, 轉換等. Witrix平臺在動態xml方面發展了一系列技術, 為文本處理引入了更多應用相關的規則, 增強了文本描述的抽象能力和表達能力. 
  
   5. 文本作為描述(description)而不是執行指令(execution). C語言的源代碼與機器碼基本上是一一對應的, 即源代碼本身所表達的就是指令的執行過程. 而在Web應用領域, HTML語言僅僅是聲明界面上需要展現什么, 但是如何去實現是由通用的解析引擎負責,它并不是我們關注的重點. 描述需要結合詮釋(解釋)才能夠產生實際的運行效果, 才能對現實的物理世界產生影響.這在某種程度上實際上是延遲了執行過程. 一種描述可以對應多種詮釋, 例如同樣的元數據在前臺可以用來生成界面,在后臺可以用于生成數據庫, 進行數據有效性校驗等. 在特定的應用領域中,執行引擎可以是通用的, 可以獨立于描述本身不斷演化, 因此一種領域特定的描述,它所承載的內容并不是固化的, 而是可以隨著執行引擎的升級不斷增強的. 例如, 在Witrix平臺中, FlowDSL本身所做出的流程描述是穩定的, 但是隨著流程引擎不斷改進,不斷引入新的功能,所有使用DSL的已實現的應用都同步得到升級. http://canonical.javaeye.com/blog/275015
  
   6. Text = Process(Text) 這個不動點在Unix系統中得到了充分的應用: 多個小程序通過管道(Pipe)組合在一起, 可以完成相當復雜的功能. 一個更加豐富的處理模型是 XML = Process(XML). 文本描述很自然的支持多趟處理, 它使得我們可以充分利用全局知識(后續的處理過程可以使用前次處理過程收集的全局信息), 可以同時支持多個抽象層面(例如DSL的不斷動態展開). Witrix平臺中的編譯期運行技術實際上就對應于如下簡單規則: 編譯期運行產生文本輸出, 對輸出文本再次進行編譯. 通過這一遞歸模式, 可以簡單的實現動態解析與靜態描述之間的平衡. 模板(Template)技術是具有關鍵性作用的文本生成技術. out.write("<div>");out.write(value);out.write("</div>");這種 API拼接方式顯然不如<div>${value}</div>這種模板生成方式直觀且易于使用. 在Witrix平臺的tpl模板語言中, xml的規范性使得在多趟編譯過程中我們一直可以維持某種形式約束.
  
   7. 不是所有的情況下都應該使用文本. 普元EOS中所鼓吹的XML總線之類的技術是我所極力反對的. http://canonical.javaeye.com/blog/33794