一图胜千言?

一图总是胜过千言？

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?