DSL领域专用语言是什么？
所谓DSL领域专用语言(domain specific language / DSL)，其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。 DSL之于程序员正如伽南地之于以色列人，是最初也是最终的梦想。几乎自计算机发明伊始，人们就开始谈论DSL使用DSL了。而前几年随着被誉为“Web开发领域专用语言”的Ruby on Rails迅速走红，DSL又一次成为人们讨论的热点话题。 很多人都认为，DSL将会是软件业的“next big thing”。然而随着DSL的日益流行，围绕着DSL出现了很多质疑和误解，比如下面这几个：
DSL...全部
所谓DSL领域专用语言(domain specific language / DSL)，其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。
DSL之于程序员正如伽南地之于以色列人，是最初也是最终的梦想。几乎自计算机发明伊始，人们就开始谈论DSL使用DSL了。而前几年随着被誉为“Web开发领域专用语言”的Ruby on Rails迅速走红，DSL又一次成为人们讨论的热点话题。
很多人都认为，DSL将会是软件业的“next big thing”。然而随着DSL的日益流行，围绕着DSL出现了很多质疑和误解，比如下面这几个：
DSL的目标受众是非程序员，业务员或者最终用户
在很多人的心中，DSL等同于“非程序员的编程语言”(programminglanguage for non-programmers)，因此DSL的最终受众应该是非程序员，一切不直接被最终用户使用的DSL都不是真正的DSL，仅仅是另一种使代码看起来不像代码的无聊技巧。
这是一个很有趣的观点，事实上在计算编程语言发展的历史上，的的确确出现过“非程序员的编程语言”，而且还非常有名，它们就是FORTRAN，COBOL这些第一代高级语言。在当时的那个时代，计算机的主要目的是科学计算，而程序员则是专指那些摆弄开关，继电器，纸带以及汇编语言的geek们。
而计算机的主要受益者非程序员——也就是那些学者和研究员——不得不委托这些人帮助它们完成从数学公式到机器指令的转换。于是第一代高级语言的主要目的是缩短计算公式和可执行的代码之间的差距（比如Fortran），或者是简化信息管理员的日常工作（比如COBOL）。
有趣的是，恰恰是这些当年的“非程序员”把软件开发发展成了一门正当且颇为体面的职业。
其实当年的“非程序员的编程语言”与今日的DSL境况颇为相似，所不同的是，当代企业级信息系统更为复杂，所关注的焦点逐渐从计算转移到数据上，业务领域和计算机的物理过程也不再具有简单直接的对应关系了。
而且随着社会分工细化，就算是通过DSL，我们仍然不太可能把那些衣冠楚楚的HR们，销售们，部门经理们统统拉下水变成新新程序员。
我仍然要承认，以最终用户为目标受众的DSL是一个很引人侧目很有意思的主意，但是在相当长的一段时间内都是不太现实的。
或许我们需要新的方法（比如精益）来协调IT部门和业务部门，或许我们需要全新的软件工程理论，或者某些非常具有独创性的工作方式。谁知道呢，预言未来总是吃力而不讨好的，但我觉得在目前情况下，简单把DSL的受众限制在非程序员，业务员或最终用户上，是值得商榷的。
DSL ＝ 整洁的代码
这种观点与前面的观点正好相反，把DSL完全当作程序员的游戏，把一切能将代码写得整齐好看的技巧都归结为DSL。
虽然从形式上看DSL和“整洁的代码”都具有简洁清晰的特征，但并不能因此将简单将两者草率地归为等同。
从概念上说，程序的编写过程就是把业务领域中的问题通过代码或者程序模型表达出来：
由于计算机的程序模型较为单一（归根结底都是运算和存储），就算是在面向对象技术成为主流的今天，通常情况下，计算机程序不太可能做到与业务领域中的概念一致，或者具有某些直觉的对应。
也这正是因为这样，软件的修改和可维护性并没有想象中的容易。我们必须不断地将业务领域中的概念转换成相应的代码模型，然后再进行修改。这种间接性直接造成了软件的复杂度。
而DSL的主要目的就是要消除这样的复杂度（或者说，以构造DSL的复杂度代替这种复杂度），DSL就要是要以贴近业务领域的方式来构造软件。
因此，DSL的简洁性往往是一种思维上的简洁性，使我们不用费太多的气力就能看懂代码所对应的业务含义。
从这里我们可以看出DSL和“整洁的代码”的根本不同，“整洁的代码”只是泛泛的要求代码简洁易懂，而不太在意是否贴近业务领域。
比如对于一个J2EE开发者来说，DAO，DTO，FormBean，Action已经足够清晰了，但是这却跟DSL沾不上一丝的关联。DSL更注重强调使用业务词汇，尽可能贴近业务模型来编写代码，使业务模型和程序模型之间具有简洁的对应关系。
因此我们不能将DSL等同于“整洁的代码”，只能说DSL是一种“整洁的代码”而已。
DSL必须以文本代码的形式出现
Domain Specified Language顾名思义，是一种语言，因此DSL一定是文本代码形式出现的，不是通过文本代码描述的就不是DSL。
我们之所以偏爱使用文本代码，主要是由于文本代码易于修改且修改效率极高。多年来软件工程实践表明文本代码是最有效率的编辑形式。但是对于DSL，问题则有些不同。
正如我们前文所说过的，DSL首要的目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。
对于大多数业务领域而言，文本代码的形式一经足够好了，我们可以很容易通过特定格式的文本，描述业务领域中的问题。然后也确实存在着一些较为特殊的领域，在这些领域中，文本代码并不是最佳的表现形式。为了更好的贴近业务领域中的概念，我们可能回选择使用一些图形化的DSL。
比如时下颇为流行的一个DSM（Domain Specific Modeling）工具GEMS（Generic Eclipse Modeling System）中就大量地使用了不同的图形化的DSL来表述系统的各个不同侧面。
所以我们并不能简单的把DSL局限在文本形式上面。
DSL的语法应该尽可能地接近英语或者其他自然语言
由于大多数DSL是描述性的，因此我们应该尽可能地让DSL接近日常使用的英语或者其他自然语言，这样可以增强DSL的表现能力。
业务自然语言（Business Nature Language）是DSL的一个重要分支。它的产生是基于这样的一些事实：对于大多数企业应用而言，使用一些类似自然语言的语法和结构构造DSL是不错的选择；通过业务自然语言，可以推动和促进业务人员和程序员之间的沟通；类自然语言的DSL相较其他形式的DSL重用起来较为容易。
正是由于上述这些特点，BNL类DSL在DSL的实践中是最流行的。我个人就曾在三个不同的项目里实现了针对不同领域的BNL类DSL，我甚至在Smalltalk语法的基础上修改提炼，得到了一种具有通用语法表达的脚本语言。
利用它可以方便地构造DSL。
虽然BNL是我实践得最多也是最为喜爱的一种DSL形式，通过前文的分析，我们仍然不能把它当作唯一的DSL形式。我们必须时刻谨记，DSL的首要目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。
合理且恰当地选择语法形式永远是构造DSL的重中之重。收起
