面向语言编程：超越面向对象编程的革命性进步？

面向语言编程：超越面向对象编程的革命性进步？

 

在巴塞罗那举行的Server Side's Java专题讨论会上，Martin Fowler和Neal Ford做了一场展示面向语言编程的重要报告。Fowler曾撰文将面向语言编程定义为“围绕一组领域特定语言来构建软件的编程风格”。Fowler和Ford又进一步发展了其中的一些想法（可参见Fowler at Jaoo 2006），并提出了“超越面向对象编程的革命性进步”的可能性。

 

面向对象编程以分层结构和树状的抽象提供了一种有用的建模范式。然而现实并不总是按层次组织的，Neal Ford指出。现实的“盘根错节，彼此联系”是很难用理想化的树状画面来勾勒其模型的。其结果就是现在广泛使用的aspects和XML，它们渐渐地增加了复杂性，并侵蚀了我们实施抽象的原意。为了弥补这个问题，抽象的水平应该再次提升，因此Ford建议用语言取代分层来作为建模机制。

 

按照Martin Fowler的说法，面向对象的领域建模让我们得以“汇集词汇”，但语法——将词汇组合起来的方法——却是缺失的；DSL补足了语法的方面。因此面向语言编程引导我们“从思考词汇，即对象，走向一种结合了词汇和语法的语言观念。”

 

对Neal Ford来说，用DSL来作为一种新的抽象机制令他特别感兴趣的是，它能填补上下文的空缺。在缺乏上下文的环境中，你要“从最基本的共识着手并解释所有的细节”。这就是你与API和框架沟通的方式，因为它们没有“任何内建的上下文”。因此代码中总是不断重复一些上下文，以致成了干扰。相反DSL“总是有着隐含的上下文，上下文几乎从不露面，就算露面也是很少很少，通常最多一次”。因此我们不必一再地提供上下文信息，于是代码更具可读性，也更有表现力。

 

Fowler和Ford都强调了可读性的重要。他们认为DSL的动机经常被误解。目的并不是为了让业务分析师能够自己写代码，而是为了让他们能够阅读和检验代码，从而填补专业开发者和业务人员之间的罅隙。

 

有些人厌恶使用面向语言编程的风格，因为他们担心维护的问题以及增加的学习负担，特别是在缺乏强大的IDE来处理这些纯文字的DSL的情况下。Fowler最近在一篇文章中反对说“大一点的框架[……]带来的挑战一点都不比学一门语言少”，他再次强调了单一语言编写的项目的复杂性。并且，Neal Ford强调说如果一门DSL很难读，那么它的设计就是很糟糕的，因为“[使用DSL的]目的之一就是为了创造出更容易阅读的代码”。

 

至于IDE支持，现今至少有三家主要厂商正为面向语言编程提供这一类工具：Charles Simonyi开发的Intentional Software，Microsoft的Software Factories和JetBrains开发的Meta Programming System。这些工具，Martin Fowler称之为语言工作台（Language Workbench），让设计并使用DSL变得更加简单。这些工具提高了面向语言编程的竞争优势，虽然Fowler相信“还要过几年大多数人才会考虑用[语言工作台]来开发实际的项目。”

 

你怎么看？面向语言编程有机会成为“下一位明星”吗？语言工作台的能力会在多大程度上影响你在项目中采用DSL的决策呢？

 

 

Language-oriented programming : an evolutionary step beyond object-oriented programming?

 

At a TSS' Barcelona event Martin Fowler and Neal Ford did a keynote presentation on language-oriented programming, summarized here. In his earlier article, Fowler defined this concept as “the general style of development which operates about the idea of building software around a set of domain specific languages”. Fowler and Ford further develop some of the ideas presented by Fowler at Jaoo 2006 and question the eventuality of an “evolutionary step beyond object-oriented programming”.

 

Object oriented programming provides a useful modelling paradigm based on hierarchies and tree shaped abstractions. Reality however is not always hierarchical, highlights Neal Ford. Its “tangled branches and interconnections” are rather difficult to model with idealized tree pictures. And this results in a widespread use of aspects and XML and eventually adds complexity undermining the very purpose of abstraction. To remedy to this issue the abstraction level should be upgraded and to this end Ford suggests using languages rather than hierarchies as a modelling mechanism. 

According to Martin Fowler object-oriented domain modelling allows to “build up a vocabulary” but the grammar – ways to combine these vocabularies – is not defined; DSLs add this grammar side. Therefore language-oriented programming inducts “this shift of moving from thinking about vocabulary, which is objects, to the notion of a language that combines vocabulary and grammar.”

For Neal Ford, what makes the use of DSLs as a new abstraction mechanism particularly interesting is its ability to supply context. In a context free environment one should “start at the lowest level possible of understanding and have to explain every single detail”. This is the way one talks to APIs and frameworks because they do not have "any sort of context built into" them. Hence the code is full of repeated context often perceived as noise. DSLs on the contrary “always have an implicit context that shows up either not at all or shows up in a very, very light way and usually at the most one time”. Thus this context doesn’t have to be supplied over and over again, which makes the code more readable and more expressive.

Both Fowler and Ford stress how critical the readability issue is. They insist that the purpose of DSLs is often misunderstood. It is not to make it possible for business analysts to write code but to make it possible for them to read and to review it, in order to bridge the gap separating professional developers and business people.

Some are reluctant to use the language oriented programming style because of possible maintainability issues and increasing learning burden, especially given the lack of rich IDEs for the plain text DSLs. Fowler, who argued in his recent article that “larger frameworks […] present as much of a challenge to learn as a language”, emphasizes again the complexity of projects written in a single language. Moreover, Neal Ford stresses that if a DSL is hard to read then it was very poorly designed because “one of the goals [of using DSLs is] to create more readable code”.

As for IDE support there are today at least three major vendors offering this kind of tooling to support language oriented programming: Intentional Software developed by Charles Simonyi, Microsoft’s Software Factories, Meta Programming System developed by JetBrains. These tools, referred to as Language Workbenches by Martin Fowler, make it easier to design and then to use DSLs. This increases the competitive advantage of the language oriented programming style even though Fowler believes that it “is going to be a few years before most people can think about using [Language Workbenches] for real projects.”

What is your opinion? Does language oriented programming have a chance to become “the next big thing”? And to which extent the availability of language workbenches tools could affect your decision to use DSLs on your projects?

 

 

附英文原文网址：http://www.infoq.com/news/2007/09/Language-oriented-programming