所謂領域專用語言（domain specific language / dsl），其基本思想是「求專不求全」，不像通用目的語言那樣目標範圍涵蓋一切軟體問題，而是專門針對某一特定問題的計算機語言。dsl之於程式設計師正如伽南地之於以色列人，是最初也是最終的夢想。幾乎自計算機發明伊始，人們就開始談論dsl使用dsl了。而前幾年隨著被譽為「web開發領域專用語言」的ruby on rails迅速走紅，dsl又一次成為人們討論的熱點話題。很多人都認為，dsl將會是軟體業的「next big thing」。然而隨著dsl的日益流行，圍繞著dsl出現了很多質疑和誤解，比如下面這幾個：
1. dsl的目標受眾是非程式設計師，業務員或者終端使用者
在很多人的心中，dsl等同於「非程式設計師的程式語言」(programminglanguage for non-programmers)，因此dsl的最終受眾應該是非程式設計師，一切不直接被終端使用者使用的dsl都不是真正的dsl，僅僅是另一種使**看起來不像**的無聊技巧。
這是乙個很有趣的觀點，事實上在計算程式語言發展的歷史上，的的確確出現過「非程式設計師的程式語言」，而且還非常有名，它們就是fortran，cobol這些第一代高階語言。在當時的那個時代，計算機的主要目的是科學計算，而程式設計師則是專指那些擺弄開關，繼電器，紙帶以及組合語言的geek們。而計算機的主要受益者非程式設計師——也就是那些學者和研究員——不得不委託這些人幫助它們完成從數學公式到機器指令的轉換。於是第一代高階語言的主要目的是縮短計算公式和可執行的**之間的差距（比如fortran），或者是簡化資訊管理員的日常工作（比如cobol）。有趣的是，恰恰是這些當年的「非程式設計師」把軟體開發發展成了一門正當且頗為體面的職業。
其實當年的「非程式設計師的程式語言」與今日的dsl境況頗為相似，所不同的是，當代企業級資訊系統更為複雜，所關注的焦點逐漸從計算轉移到資料上，業務領域和計算機的物理過程也不再具有簡單直接的對應關係了。而且隨著社會分工細化，就算是通過dsl，我們仍然不太可能把那些衣冠楚楚的hr們，銷售們，部門經理們統統拉下水變成新新程式設計師。
我仍然要承認，以終端使用者為目標受眾的dsl是乙個很引人側目很有意思的主意，但是在相當長的一段時間內都是不太現實的。或許我們需要新的方法（比如精益）來協調it部門和業務部門，或許我們需要全新的軟體工程理論，或者某些非常具有獨創性的工作方式。誰知道呢，預言未來總是吃力而不討好的，但我覺得在目前情況下，簡單把dsl的受眾限制在非程式設計師，業務員或終端使用者上，是值得商榷的。
2.dsl ＝ 整潔的**
這種觀點與前面的觀點正好相反，把dsl完全當作程式設計師的遊戲，把一切能將**寫得整齊好看的技巧都歸結為dsl。
雖然從形式上看dsl和「整潔的**」都具有簡潔清晰的特徵，但並不能因此將簡單將兩者草率地歸為等同。從概念上說，程式的編寫過程就是把業務領域中的問題通過**或者程式模型表達出來：
由於計算機的程式模型較為單一（歸根結底都是運算和儲存），就算是在物件導向技術成為主流的今天，通常情況下，電腦程式不太可能做到與業務領域中的概念一致，或者具有某些直覺的對應。 也這正是因為這樣，軟體的修改和可維護性並沒有想象中的容易。我們必須不斷地將業務領域中的概念轉換成相應的**模型，然後再進行修改。這種間接性直接造成了軟體的複雜度。
而dsl的主要目的就是要消除這樣的複雜度（或者說，以構造dsl的複雜度代替這種複雜度），dsl就要是要以貼近業務領域的方式來構造軟體。因此，dsl的簡潔性往往是一種思維上的簡潔性，使我們不用費太多的氣力就能看懂**所對應的業務含義。
從這裡我們可以看出dsl和「整潔的**」的根本不同，「整潔的**」只是泛泛的要求**簡潔易懂，而不太在意是否貼近業務領域。比如對於乙個j2ee開發者來說，dao，dto，formbean，action已經足夠清晰了，但是這卻跟dsl沾不上一絲的關聯。dsl更注重強調使用業務詞彙，盡可能貼近業務模型來編寫**，使業務模型和程式模型之間具有簡潔的對應關係。
因此我們不能將dsl等同於「整潔的**」，只能說dsl是一種「整潔的**」而已。
3.dsl必須以文字**的形式出現
domain specified language顧名思義，是一種語言，因此dsl一定是文字**形式出現的，不是通過文字**描述的就不是dsl。
我們之所以偏愛使用文字**，主要是由於文字**易於修改且修改效率極高。多年來軟體工程實踐表明文字**是最有效率的編輯形式。但是對於dsl，問題則有些不同。
正如我們前文所說過的，dsl首要的目的，是使程式盡可能地接近業務領域中的問題，從而消除不必要的間接性和複雜性。對於大多數業務領域而言，文字**的形式一經足夠好了，我們可以很容易通過特定格式的文字，描述業務領域中的問題。然後也確實存在著一些較為特殊的領域，在這些領域中，文字**並不是最佳的表現形式。為了更好的貼近業務領域中的概念，我們可能回選擇使用一些圖形化的dsl。比如時下頗為流行的乙個dsm（domain specific modeling）工具gems（generic eclipse modeling system）中就大量地使用了不同的圖形化的dsl來表述系統的各個不同側面。所以我們並不能簡單的把dsl侷限在文字形式上面。
4.dsl的語法應該盡可能地接近英語或者其他自然語言
由於大多數dsl是描述性的，因此我們應該盡可能地讓dsl接近日常使用的英語或者其他自然語言，這樣可以增強dsl的表現能力。
業務自然語言（business nature language）是dsl的乙個重要分支。它的產生是基於這樣的一些事實：對於大多數企業應用而言，使用一些類似自然語言的語法和結構構造dsl是不錯的選擇；通過業務自然語言，可以推動和促進業務人員和程式設計師之間的溝通；類自然語言的dsl相較其他形式的dsl重用起來較為容易。正是由於上述這些特點，bnl類dsl在dsl的實踐中是最流行的。我個人就曾在三個不同的專案裡實現了針對不同領域的bnl類dsl，我甚至在smalltalk語法的基礎上修改提煉，得到了一種具有通用語法表達的指令碼語言。利用它可以方便地構造dsl。
雖然bnl是我實踐得最多也是最為喜愛的一種dsl形式，通過前文的分析，我們仍然不能把它當作唯一的dsl形式。我們必須時刻謹記，dsl的首要目的，是使程式盡可能地接近業務領域中的問題，從而消除不必要的間接性和複雜性。合理且恰當地選擇語法形式永遠是構造dsl的重中之重。
Kotlin領域特定語言（DSL）
一 dsl的概念 只在特定領域內使用的語言 例如 html gradle sql等等 特點 計算機程式語言 具有語言的表達能力 有限的表達能力 關注某個特定的領域 二 下面用dsl來寫乙個例子吧 需要下面五個類 三 建立乙個node節點的介面 package cn.kotliner.kotlin a...
Kotlin領域特定語言（DSL）
一 dsl的概念 只在特定領域內使用的語言 例如 html gradle sql等等 特點 計算機程式語言 具有語言的表達能力 有限的表達能力 關注某個特定的領域 二 下面用dsl來寫乙個例子吧 需要下面五個類 三 建立乙個node節點的介面 package cn.kotliner.kotlin a...
《領域特定語言》一2 3DSL的問題
前面已經討論了何時該採用dsl，接下來就該談論什麼時候不該採用dsl，或者至少是使用dsl應注意的問題。從根本上說，不使用dsl的唯一原因就是，在你的場景下，使用dsl得不到任何好處，或者，至少是dsl的好處不足以抵消構建它的成本。雖然dsl在有些場合下適用，但同樣會帶來一些問題。總的來說，我認為通...