关于 "代码即文档"

我一直在设想下一代程序设计语言, 我想它应该是基于组件的, 相当于现在OO里一个类的概念的东西是一个独立组件的源码. 我觉得至关重要的一个新语言特性是组件之间通过接口相互引用时的角色概念. 这可以从OO平滑引申出来: 可以认为OO的一个组件(比如一个COM对象或者JavaBean)只有一个引用者角色, 那就是调用者, 调用者可以调用任何声明出来的公开接口方法, 也就是所有这个组件的边界方法和属性读写器. 不管是组件容器用于维护性的调用还是其他组件对它的请求性的调用, 在语法的级别上看起来地位都是相同的, 那么如何告诉使用这个组件的应用程序员: 哪些方法适于他去调用, 而另一些不是为他准备的? 这个工作, 就推到了代码文档的头上. 实际上在初始设计一个编程语言的时候, 并没有难以克服的困难妨碍我们制定出表达类似语义的语法结构, 而是早些时候软件开发业还没有达到企业/组件这个规模级别, 没有这种需要. 而当这种需求已经发展出来的时候, 我们又已经背上了一些历史包袱, 受沿袭所致很难完全推翻已有体系结构. 不过变革是迟早的事儿, 程序设计语言也一样, 当结构化编程时代的遗老遗少最终不堪重负, 就算加上了面向对象的特性也不能很好适应组件时代的规模化要求时, 就会有新的血统走上历史舞台. 回到 "代码即文档" 的问题上来, 可以看到其实目前主流编程语言的 "文档观念" 还相当朴素, 他们的首要目标是完成 "算法" 和 "功能", 还没有感觉到文档和程序逻辑应该有什么直观联系. JavaDoc是个创举? 没错, 它让代码文档的编写不用离开编程语言, 并且透过一些非官方的手段还能检查规定范围内文档的完备性. 但这个地步仍然没有让程序文档的编写成为有正规组织, 有标准安排的编程活动的正式组成部分. 仍然是在语言语法上缺乏语素和约束规则. 在这个环境基础上, 把代码写得简明易懂, 起到文档的作用, 还只能是少数优秀工匠所能掌握的一门手艺. 要工业化提高生产质量和效率, 那就得发明新的操作简单的机器来生产程序产品, 也就是新的程序设计语言和开发平台.

 

引用

　　    ... 

　　因为一直能上网，倒是也一直能读到人家的blog，最近看到两篇不错的blog。一篇是...；还有一篇是曾登高转载的《The Rule of Method Design》。尤其是后面这篇，我又是喜欢又是后悔，怎么没有早点把自己的思考总结下来。因为最近我也一直在思考“代码即文档”这样一个概念，什么样的代码，才能让人一看就懂呢？不是注释，而是代码本身，应该足够好懂，应该命名清晰，应该参数合理。。。总之，跟Jeffrey Palermo是如出一辙，只是如今说来，也是马后炮啊。

 

...