IntelliJ老板的一篇文章Language Oriented Programming: The Next Programming Paradigm
英文 http://www.onboard.jetbrains.com/articles/04/10/lop/
中文 http://blog.csdn.net/chelsea/archive/2005/02/17/290486.aspx
Martin Follower的一篇文章 Language Workbenches: The Killer-App for Domain Specific Languages?
http://www.martinfowler.com/articles/languageWorkbench.html
概念解释：
DSL(Domain Specific Language): a limited form of computer language designed for a specific class of problems, 例如SQL语言，xml配置文件。
LOP(Language
Oriented Programming): the general style of development which operates
about the idea of building software around a set of domain specific
languages.
Language Workbench： the new breed of tools to do language oriented programming
LOP不是一个新的提法，不过随着前段时间MDA(Model Driven Architecture)概念的热炒，LOP似乎终于熬到了应用层面。Sergey Dmitriev的文章中批评了主流程序语言的不足，大概有这么几条：
1. 通用语言表达能力(expressive power)很差，Time Delay to Implement Ideas
2. 领域概念的表达分散在实现代码中，整体图像迷失，因而Understanding and Maintaining Existing Code很困难。
3. 类库等不是用领域概念表达的，因而Domain Learning Curve很陡峭。
这
些都是标准的陈词滥调。地球人都知道，从问题描述到软件实现之间存在着巨大的逻辑障碍，这种障碍有一部分是本质性的，即源于我们认识中的创造性因素，而另
一部分是技术性的，即源于我们使用的技术手段的限制。我们所能想到的解决的办法就是尽量提高解决方法的抽象层次,
提升到所谓的领域层面，从而消解技术性障碍，同时辅助创造性发展。当我们的脑子里不再充斥着各种技术性细节的时候，大概就可以集中精力做些创造性工作了。
LOP把这些老帐又翻出来，到底它提供了什么新意？下面我们简要分析一下LOP方案中概念的含义。
1. 领域(Domain)。
计算机语言与自然语言在使用上是有着深刻不同的。自然语言只是传递着信息，而计算机语言还要负责具体干事情，即计算机语言要同时说明怎么做和怎么用。做与
用这是两个不同的领域，例如我现在编了一个时光机器的软件，上面就一按钮，只要轻轻一按，嗖的一声我就回到了500年前。怎么样，使用简单吧，但实现呢？
我们当然希望在一个领域中使用最适合它的描述方法和控制指令。目前主流语言都是面向机器实现领域的(是实现领域的DSL?)，加上Von
Neumann串性化体系的限制,
强迫我们用动态过程来实现静态概念，更加剧了它对使用领域描述的不适应性。我们所要做的就是将做与用尽量分离，但同时尽量增大用的灵活性，domain
representation不仅仅给最终用户用，还给程序员用。能在使用领域概念范围内解决的问题，我们不要将其拖延到实现领域。在领域间进行转换，总
存在信息转换成本，甚至会造成信息失真。例如，一幅画看起来结构很简单，但是用自然语言描述起来都相当困难，更别说转换为计算机语言了（当然，这个例子很
有可能是误导的，因为涉及到不同的感官，其中的区别是非常深刻的，无法用单一的原因去解释）。所谓领域区分，最重要的还是使用领域与实现领域的区分（不同
的复杂性，不同的表现形式...），而不仅仅是业务领域与计算机领域的划分。在业务领域内部我们也要区分使用与实现。
2. 领域特定语言(DSL)
语言与库的最大差别在于语素可以自由组合，以极低的代价构造出无数可验证的结构，而库函数的组合和搭配调用是冗长的，受限的，难以进行校验的。DSL强大
的描述能力和推理能力其实是通过放弃其通用建模能力而实现的。最有效的DSL必须弱于图灵机，必须将大量做的过程分离出去，必须引入大量的领域概念（本
体）。
在引入外部概念的时候，DSL会将其转义为领域概念之后使用，从而消除歧义性并降低理解难度。
DSL不是在通用环境下工作，而是在明确受限的context下工作，因而概念的表达可以更加简洁，而且领域概念之间还可以通过context构成一种整体性，例如非此即彼。
witrix平台中的tpl模板引擎在一定程度上可以看作是一种DSL tools, 我也一直推动tpl在这个方向上发展。tpl具有强大的领域抽象能力,例如
弹出一个选择系统用户的窗口，直接实现为
＜a href="select_user.jsp?deptId=1"＞选择用户＜a＞
封装为tag之后，使用形式变为
＜app:选择用户 部门编号="1" /＞
经过转换之后，这里的调用不再是API含义，不再是说明怎么做，而是描述用什么。tpl中的标签可以使用调用时明确指定的参数，也可以从全局
context中导入隐含的变量，从而依赖于所在领域的假定。例如，我们的很多界面控件需要与后台交互，依赖于后台jsplet框架，因而这些tpl标签
选择自动导入$thisObj和objectName等变量。领域抽象与context依赖其实正是DSL的精华所在。
(关于DSL，有些人可能会将其等价于规则引擎(rule engine), 这其实是一种误解。规则引擎实现的是条件空间的分解与合并，它是一个独立的技术，与DSL并没有必然的联系)
3. 语言工作台(Workbench)
Workbench是LOP的使能技术。我们希望自由的构造DSL,必然需要对结构具有强大的控制能力。而文本语言总是线性的，静态的。看看现在对自然语
言的研究吧，显然我们对于怎样在线性文本中塞入更多的结构缺乏本质性的认识。我们人为构造的语言，限于表现形式，其结构都异常的贫乏。计算机的脑袋是简单
的，于是，我们想到增加维度，通过复杂的工具配合，来实现多层次，多视角,
动态的结构控制。在我看来，很多时候这是一种无奈之举，当然也确实是目前唯一可行的办法。
工具复杂了之后，造成的本质性障碍在于结构上的僵化，其具体表现之一就是所谓的厂家锁定,一种结构融合上的困难。不同厂家产品的结构具有巨大的差异而无法
互相交互。xml其实正是为了解决这种结构交互困难而产生的，所以我更希望看到基于xml的工作。而在xml的形式下，能够实施的结构变换现在也在不断发
展当中，AOP, XSLT等等。