What Is Wrong with Mainstream Programming
你知道這則古老的諺語:"If it ain’t broke, don’t fix it". 主流編程方法很明顯不完整,我見過它帶來的很多問題,而大部分滋生于這樣一個事實:general-purpose的語言沒有一種方法來完全支持任意的領域,同樣也沒有一種統一的domain-specific language;下面是將被LOP解決的主流編程中三個最糟糕的問題:
Time Delay to Implement Ideas
對我來說,最嚴重的問題是,在我確切的知道如何解決一個問題,和我通過一個程序成功的向計算機傳達解決方案之間,有一個很長的時間差;我可以用幾個小時的時間向另外的程序員解釋問題和解決方案,而將解決方案編碼到計算機中將花費長的多的時間;這是因為對另外的程序員,我可以使用表達能力非常豐富的自然語言,而對計算機,我只能使用某種表達能力差很多的general-purpose的編程語言;今天的編程語言只能表達幾十種概念,而自然語言能夠簡潔的表達千萬種概念;因此,向另外的程序員解釋問題,我可以表達很高層的思想,而對計算機,我必須表達每一步的每一個細節
在主流編程中,大部分花在“編程”上的時間,實際上是在尋找用編程層次的抽象的術語來表達自然語言的概念的方法,而這是很困難的,沒多少創造性的,或多或少是一種時間的浪費
舉個例子,今天大量的開發時間花費在面向對象的設計(OOD)上,在程序員表達類、繼承、關聯等方面這確實是一種還算有創造性的過程;這項實踐的目的是用面向對象的術語,如類和方法,來表達程序;OOD的過程是必要的,因為諸如類和方法等是面向對象語言能夠理解的僅有的抽象,它看起來是必要和有創造性的,但是使用Language Oriented Programming,OOD根本就不需要
Understanding and Maintaining Existing Code
下一個問題是理解和維護現存代碼;不管它是另一個程序員寫的還是我寫的,問題都一樣;因為general-purpose的語言需要我把高層的領域概念翻譯為低層的編程語言特性,在最終的程序中,很多高度概括的視角、藍圖都丟失了;當我在以后重新翻閱程序時,我不得不通過逆向工程來了解我最初的意圖是什么,我頭腦中的模型是什么;至少,我必須在腦海中重新建造最初在翻譯到general-purpose的編程語言的過程中丟失的信息
解決這個問題的傳統方法是寫注釋或其它形式的文檔來記錄設計信息和模型信息,已經有幾個方面的因素證明了這是一種脆弱的解決方案,至少包括編寫這些輔助文檔的成本、以及文檔和代碼逐漸不同步的趨勢;并且,還有一個沒被廣泛認識到的事實,就是文檔并不能直接連接到它所記錄的概念;注釋和源代碼被綁定到同一個地方,但是概念可能在源代碼的多個地方被表達;其它類型的文檔徹底從源代碼中分離出來,只能間接的引用源代碼;理想情況下,代碼應該是自我描述的,我應該只閱讀代碼本身來理解代碼,而不是什么注釋和外部的文檔
Domain Learning Curve
第三個主要的問題是對語言進行領域相關的擴展;例如,在OOP中擴展語言的主要方法是使用類庫;問題是類庫不是用領域概念相關的術語來表達的,而是用低層的 general-purpose的抽象諸如類和方法等來表達;因此,庫很少能夠直接表述領域概念,它們必須引入額外的枝節(如一個類的運行時行為)來完成到領域概念的映射;兩個很好的常見例子是GUI庫和Database庫
文章來源于領測軟件測試網 http://www.kjueaiud.com/