posts - 176, comments - 240, trackbacks - 0, articles - 7

[导入]关于LOP(Language Oriented Programming)

Posted on 2006-01-23 23:13 canonical 阅读(761) 评论(0)  编辑  收藏 所属分类: 设计理论

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等等。

只有注册用户登录后才能发表评论。


网站导航: