canonical

不知道你那个Witrix，，商业上发展得如何。

我曾参与创建过一个属于找死型的国内做通用开发工具的公司。虽然后来痛感国内通用软件市场的腐烂转而做起了电子行业，不过关于开发工具和语言的思考一直没有停止。

和这里的人相比，我对现在这些新的语言和发展有些隔膜了，不过很多东西由于能和我的思考对应上，虽然缺少实践也能理解一二。

在你的文章中看到了不少同感，尝试做点交流，虽然很难互相理解，但我可以尝试表达一下：

1 受到认识论的一些启发，我想我们首先应该将软件开发的过程定义为一个科学发现的过程，一个通过理性分析建构逻辑模型的过程，是在理论-事实的迭代中逐渐完善的。这一点已经是共识，但目前的工具尚未对这个过程提供完好的支持。这我们可以从系统重构时程序员大量的查找替换拷贝粘贴就可以看出来。

2 不能以轻视的态度看待所谓的语法糖，抛开OO的所谓哲学，仅仅把那些所谓的抽象看作语法糖。其实没有什么抽象的概念，当我们说“继承”，其实只不过是在说一段代码，而且一般来说是在设计时运行的代码罢了。如果“继承”代码在运行时运行，那就变成了一种具有病毒特征的高效的动态语言。

3 设计时与运行时的关系，尚未得到彻底的分析，我想一旦深入理解了这种关系，所谓静态语言与动态语言的鸿沟就不复存在，我们可以在效率与灵活性之间从容取舍。

4 再来看所谓的现代开发工具对效率的要求不高的说法，也是有前提的。我们只不过感受不到效率的限制而已。事实上，对效率的要求，已经使我们被迫放弃一些看起来优雅的设计。举一个极端的例子，在位图编程中，我们无法把单独的像素看作一个一个的对象，即使这可以让程序看起来简单。如何让优雅与高效并存，也是一个不小的课题。虽然完全并存是不可能的，但我以为现有的语言在这方面的提升空间还相当大。

5 程序员之间的交流，文档是靠不住的，唯一靠得住的就是代码，包括静态的，尤其是动态运行的。未来的开发工具应该正视这个问题，为程序员之间的交流提供优秀的方案，这看起来是提高团队工作效率的最有效的方法了。举一个另类的例子，可不可以在一段代码上附加一个录音注释呢？

6 AOP所揭示的是一个方向，但目前做得远远不够。设想一下我们在设计程序的过程中头脑中浮现出来的各种隐喻，指导我们敲下代码的头脑中的模型。当我们对接班的程序员介绍的时候，是先给他讲这些隐喻，模型更有效率呢，还是直接看一段糅合了N个思路的代码更有效率？其实，在浏览代码时，我们也只能通过恢复设计者的数个思路来理解，而不是直接通过代码来理解。

7 让用户编程，似乎是个疯狂的想法，但在某些时候，编程比操作按钮来得更加友好。以此为思路，任何软件都是一个自开发的工具。

8 大教堂与市集的愿景是好的，但缺少一条最根本的东西，商业利益驱动，不同于那些软件共产主义分子，我认为一个灵活的市场机制，是发挥每个人效能的最佳环境。我们未来应不必在opensource和closesource之间进行取舍，这也是开发工具所应支持的。

9 在一个复杂的继承关系中，基础类的修改往往意味着新产生无数的Bug。其实，如果在运行时引入版本概念，我们往往可以对系统进行细微的，不那么符合OO的小修改，但是却能很好的工作，也能很好的理解。至于不符合审美的问题，如果是工程，那么就此结束，如果要复用，那么再继续调整。OK，这里谈到我的一个核心概念，把继承当作版本来处理，版本管理所能处理的要更加广泛灵活，而继承只不过是一个特例的应用而已。

目前我们主要基于witrix研发行业软件，本身并无意推广witrix平台。现在witrix所承载的核心应用对它的灵活性和性能都有着很高的要求。
1. witrix技术的创新之处在于提供了程序结构的新的抽象和融合方式，它所带来的价值主要是程序的持续改进能力。在公司里我们是严禁拷贝粘贴的。可以重用的业务逻辑总可以抽象为某种技术实体。
2. domain specific的语法我们认为非常重要。很多人倾向于使用非常强大的语言，这种语言允许构造所有复杂的局部结构，但是在我们看来，再复杂的通用语言也无法涵盖各异的业务逻辑，而语言本身提供的抽象能力至关重要。同时我们还非常关注于抽象出的技术结构的稳定性。假如做一件事情有n种语义等价的方式，而且没有一种强制手段可以进行形式校验，则任何一种抽象得到的结构都是不稳定的，因为我们总是会受到各种诱惑偏离一种固定的形式，最终造成形式的解体。
3. 我们在编译期作了很多工作，这是解决系统结构问题的一种重要手段。在没有得到全部信息的情况下（没有运行时的数据信息），即使没有类型概念，我们仍然可以在结构方面作很多文章。
4. 现在很多情况下其实是没有很好的抽象方式。比如说，如果把位图的每个像素都看作一个具有自我活动能力的对象，我们遇到的问题首先是巨大的管理成本，这远不如把它看作只接受外部控制的数据信息更直观，更简单。一些所谓优雅的设计只是在最模糊的印象上似乎很时尚， 但是真正细致到细节的时候，它远不能提供我们所需要的结构控制能力。
5. 代码是交流的重要工具。witrix设计的一个重要目标就是代码的可描述性，编码的过程就是描述系统结构的过程。我们正在尽力缩小需求描述与代码结构之间的概念差距。但是很多时候代码是信息不完全的，有些信息我们写在了代码之外的文档中，特别是一个设计的原因是什么，为什么采用当前的处理方式。
6. AOP的原始形式存在一些隐蔽的问题，直接应用AOP效果是有限的。在witrix中我们是对AOP的概念体系进行了补充，才定义出足够强大的结构组合方式。
7. 对程序员来说代码更加便捷，但是工具仍然是有效的，它可以限制程序的可能性，大大提高我们构造某种业务流程的可靠性。
8. 商业是一方面，人的精神和传统是另一方面。
9. witrix目前就在运行时管理着大量的代码版本，继承只是一种初级的结构融合手段。

对设计有兴趣的朋友可以通过 canonical.cqh@gmail.com联系我