一图胜千言?

  • Niclas Nilsson
  • 郭晓刚

2007 年 11 月 10 日

话题:微软IDE架构语言 & 开发

一图总是胜过千言?

Dean Wampler在新文章《为什么我们要写代码而不只是画图就好》中主张,在软件行业里,前面那句话通常要反过来说才对。

图形表示法的拥护者们已经期盼了很久,希望能达到只需要画图不必写文本代码的境界。多年来,已经有一些图形编程环境来了,又走了。

要是一图真的胜过千言,那为什么它还没有实现呢?

曾被广泛应用的图形编程环境并不多见,但也有独树一帜的。LabVIEW可能是其中最著名的一个,不过它主要是被测试者所使用(以及拥有神奇的 Lego 玩具的小孩)——而非一般的开发者。

为什么会这样?很可能是因为在软件开发中要照顾太多的细节。因此很难创造出一种图形语言能表达出这种复杂性,而又不致让阅读的人负担过重。如果用图形来表示编程结构,我们需要把图形映射到一种(常常是)抽象的概念方能理解其含义。难的是不要落入一个经典的陷阱。而因为我们需要与其他开发者交流,我们又的确需要能适用于种种情况的充分的词汇。

Dean 写道:

那我们不能用一种表述力充足的图形表示法吗?当然可以,只不过我们会遇到实用的问题——用文字来书写细节总比画出来要快。

几年前我为某著名公司开发面向 Java 开发者的以 UML 为基础的工具时,就遇到了这个现实问题。工具的 UI 可以做得更高效,但绝对没法超过打字的速度。

不过,这取决于你在代码中建立的抽象有多强。如果做得不好,你可能需要一千个词才能表示出一张图就能说明白的内容。而且你及你的同事每次阅读代码的时候都需要“解码”。

目前的领域特定语言运动就明确地专注在这一点:

有些语言相当繁冗也是事实。这是领域特定语言(DSL)将会扮演更重要角色的一个方面。一个设计良好的 DSL 能让你简洁地表述那些高抽象层次的概念。

Dean 所说的是文字的 DSL,但 Metacase 等公司正在设计图形建模语言,而 Microsoft 也采取了类似的路径去开发创建图形 DSL 的工具,来完成他们对软件工厂(Software Factory)的设计图景。

Arnon Rotem-Gal-Oz如此描述图形 DSL 的局限:

跟以减少代码为出发点的 DSL 不同,以建模为出发点的软件工厂、MDA 等把目标定得太高,因而提供的价值太少,或者在代码生成的隔阂上受累太多(生成的代码太过一般化,距离方案的实际需要太远)。

Arnon 也明确地评价了一图是否真的胜过千言:

如果你把模型看作是纲领性的框架,那么你可以按自己的意愿提高抽象的层次,进而比较明晰地表达你的观点,那么这句话成立。然而,当你需要把模型建得非常具体,从而得以进行代码生成——在这种情况下,用代码来建模,再搭配自动生成或预先建立的 DSL 和框架,会更加合宜。

讽刺的是,运用图形是掌握一个复杂的代码基的一种好方式。InfoQ 最近发表了与 Erik Doernenburg 进行的一次关于软件视觉化的采访,在其中 Erik 解释了从不同角度视觉化一个系统或者一个代码基的各种方式。运用视觉化方法,可以快速地聚焦到其他方法难以发现的反常之处。不过这与图形化地建造软件并不是一回事。

Dean 最后解释说他并不认为图形表示法没有存在的空间,但是:

就一般情况来说,用简洁的语言加上设计良好的 API 和 DSL 来编写的代码,对上图形驱动的方式仍然是必胜的。

可是另一方面,Intentional Software会对你说,代码和图形都只不过是同一个模型的不同投射罢了。

查看英文原文:Is a picture always worth a thousand words?
微软IDE架构语言 & 开发