學習這些類庫不是一項簡單的任務，即使你是個領域專家；因為從領域到語言的映射不是直接的，你必須學習這種映射；這意味著一個陡峭的學習曲線；通常我們試圖用大量的指南和文檔來解決這個問題，但是學習這些將花費大量時間；當一個類庫變得復雜的時候，它也變得更難以學習，程序員將因此失去學習它的動機
甚至當掌握了這種復雜的映射之后，依然還會很容易的誤用類庫，因為開發環境（像編譯器和編輯器）不能幫助你正確的使用類庫，對這些工具來說，調用一個GUI 對象的方法和調用一個DB對象的方法是一樣的：它們都只是對象上的方法調用，沒有任何更多的意思；記住哪些類和方法應該被調用，以什么順序被調用，等等，都是使用者的責任
甚至即使你既是領域專家又是類庫的使用專家，也仍然有使用類庫編寫的程序十分冗長的問題；相對簡單的領域概念需要復雜的措施來正確的調用；例如，任何用過Swing的開發者都清楚這一點；編寫簡單的程序就已經花費太長的時間了，復雜的程序甚至更糟
Details of LOP
What Is a Program in LOP?
今天，百分之九十九的程序員認為編程就是編寫一串計算機能夠執行的指令集；我們被教育說計算機建立在圖靈機模型之上，因此它們用指令集的術語來“思考”；但是這種編程的觀點是有缺陷的，它混淆了編程的目的和手段；我將為你演示LOP為什么優于傳統編程方法，但首先我必須澄清以下事實：一個LOP的程序，不是一串指令集；那么它是什么呢？
當我有一個問題要解決，我在頭腦中思考解決方案，這個解決方案用單詞、標記、概念、思想，或者任何你喜歡的稱呼來表述，它是我頭腦中如何解決問題的模型；我幾乎從未把它們想象成一堆指令集，而是我正在工作的領域中特定的具有內在聯系的概念的集合；例如，當我思考GUI領域時，我想象“這個按鈕到那邊去，這個輸入域到這邊來，這個組合框里面需要有一些數據的列表”；我甚至只是在頭腦中把它畫出來，根本不用任何言語
我之所以認為這種意念模型是一種解決方案是因為我能夠用足夠的細節向另一個程序員解釋這個模型，使他能夠坐下來編寫一個解決這個問題的程序（比如用 Java）；我不需要非得用編程語言的術語來解釋這個方案，它可以是任意形式；比如，為了解釋如何布局一個GUI的窗體，我只需要畫出這個窗體；如果繪畫有足夠的細節，繪畫本身就代表了解決方案；這種領域相關的表述應該就是程序。換句話說，應該有一種方法允許我們使用這種表述作為真正的程序，而不僅僅是與其它程序員交流的手段；于是這便導出了我對程序非正式的定義：一個程序是任何對一個問題無歧義的解決方案，或者，更精確一點：一個程序是對某個領域的某個問題的解決方案的任何使用領域相關概念表達的，精確定義的模型
這就是我認為程序員應該擁有創建他們自己的語言的自由的主要原因：這樣他們就能夠用更加自然的形式來表達解決方案；General-purpose的語言是無歧義的，但是太冗余和易于出錯；自然語言（如英語）表達能力十分豐富，但目前它難以使用因為它太不精確太不形式化了；我們需要能夠容易的創建形式化的，精確定義的，領域相關的語言；因此Language Oriented Programming將不只是編寫程序，還包括創建用來編寫程序的語言；我們的程序將被編寫的更接近問題域而不是計算機指令集領域，因此它們將非常容易的被編寫
Programs and Text
文章來源于領測軟件測試網 http://www.kjueaiud.com/
