与建一的讨论
建一：
>老师，我因为工作原因又出差来集中开发了…
你总是集中开发，可真得注意身体了。岁数一大，就不如年轻的时候扛造了。
你对于技术的思考和总结，已经越来越有高度，令我欣慰。有你这样的讨论，即
使我在小山村里也不孤独。
>简述的是在2006年到2013年我接触的web开发技术路线变化。
你提到的几种技术，我的体会是这样的：
1.J2EE SSH 与 orm/sessionbean 它们都不矛盾，算是不同的方面吧。它们不能
比较，互相作为补充吧。
2.在你所讨论的角度上，web service 与 SSH 一样，都是一种框架 (或架构) 手
段，它们在软件工程上的原则是相通的，比如倾向于你提到的封装、抽象、约
定，只不过是在这些方面的实现机制和强调的程度不同。就像XP和RUP其实并无本
质不同。
3.no sql 和 mongodb又是与orm/sessionbean类似的技术方向，数据留存。
我的感想：1.框架(和数据留存)都有不少技术，它们无所谓好坏，而是有各自不
同的优缺点 (包括学习曲线的陡峭程度、现有人员的技术程度也算特点，要作为
采用时的考量)；工程师的责任，是针对具体项目，根据这些特点优缺点选择合适
合的技术。 2.如果不建立更全局和高度的观点来看待这些技术，是危险的。
4. 框架一直在试图解决一个问题，就是如何"约束"使用者的行为，而不是增加他
们的自由，以保证他们能够以更"正确"的行为使用框架所规范的底层机制，比如
语言。在一定程度上，框架的创造者们成功了。但是同时，使用框架真正的方
法，是理解和构造它们，而不是单纯被动地被约束。理解和构造框架，需要更深
层次的理论知识，更多地探索这些成型的框架的构造原则和动机。
5. nosql一类的数据留存技术，一直在试图解决两个问题。一是提高性能，降低
负载，采用的技术手段包括分布式 (集群、云，全算分布吧) ，二是与现有技术
的结合 (动机是方便程序员使用)，比如与OO的结合，比如脱离sql。性能和负载
方面，似乎卓有成效，而与现有技术结合的方向，一部分技术似乎有这样的目
的，即能让傻瓜程序员 (我指的不是那种KISS的S，而是受到培训很少，不希望投
入时间和精力、智力)也编程序。后面这个目的，早在COBOL时代就已经有了，无
论他们取得了多少成果，我仍深感怀疑。我怀疑的原因是，创造性的工作是所有
智力活动之所以有价值的特性，而创造性工作需要严格精确地描述--没有适当的
工具和训练，我不相信正常人类可以使用正常人类语言精确描述任何意图。计算
机又不是神仙，焉能知道你想得是啥，甚至很多人自己都不明确自己想的是啥。
如果自己也不清楚，就变成了希望计算机代为决定，这涉及人是否要放弃自由意
志了。
> 曾经以为走在软件开发的路上，必须不断地在自己身上增加各种砝码，针对于具
> 体技术的砝码。然后你的重量就大了，力量就强了。结果一边走一边发现有些东
> 西慢慢变成负担，又开始甩脱直到轻松，留下的是对于负重的承受力和感知。“在
> 任何一组东西中，最重要的只占其中一小部分，约20%，其余80%的尽管是多数，
> 却是次要的。”
确实，增加的东西，一部分只是暂时的奇技淫巧、眩目的名词，短期可能效果不
错；应该减少的东西，也正是这些。应该留下来的，是基础理论。而所有的新知
识，都应该建立在自己的现有知识结构之上，是现有知识结构的一个演绎结果。
如果突然来了些新名词，却无法用我们现有的知识解释，要么，那就是我们要变
更知识结构了，要么就是这些新名词是骗人的。变更知识结构的，我遇到过的情
况是读《计算机程序的构造和解释》， (1) lamda运算与图灵机等价，所以，这
是一套不同的思考方法； (2)这很接近于Johan Linus以前对我说的，物理或电子
出身的人难以理解"模型"，可能正是因为物理和电子工程师构造出的不是数据而
是物理模型，不是对问题的认识，然后建模，而是太早套用到了似乎唯一的既定
的解决方案上。这种什么跟什么是"同构"的，在《GEB》这本大书里有深刻讨论。
确认或猜想某个问题与某个模型同构，非常重要，因为我们可以选择一个更容易
解和对条件依赖更不那么苛刻的模型。
新名词骗人的，那就太多了，大多数新名词我都先归到这一类，如果不是一眼就
能看出来好的，等它著名了再说吧。
> 集大成的东西内部未必单一。平台级的产品，就应当能兼容并包多种形式、各尽
> 其能的模块或子系统，朴素的脚本是利器。这部分是联想到你设计的仪器软件平
> 台，以前没觉得是因为眼界小。
你这一段总结，让我想起了linux内核。这两天我配置linux内核，哗哗失败，一
次又一次。解决不了的困难，如同跟高手过招，屡屡被缠住，不要说攻击，连自
守都困难得很。不过，与高手同行，毕竟收获也很大--如果能幸存下来。linux内
核的结构，我看到的只是make的配置，正有点你说的这个意思。
我的另一个体会，针对你提到的"眼界"。这几天哪位同学来着，重提到一个问
题，研究了一六十三招以后，发现别人早就实现了。前几年Johan Lilius来长春
的时候，我请教他关于整个体系性能的问题，他给我篇论文，198X的。我看了以
后拍大腿，正是我想要的。另一个问题，我当时请教的，他从理认上否定了解决
的可能性。对198X年的论文，我当时提到，这多么令人沮丧，我们头疼很久的问
题，不仅有人解决了，而且解决了三十多年，而且，我们还不知道它已经解决了。
他说，你在博士阶段 (或者做科学研究) 所受到的训练，正是为了提高这种能力。
我们经常看到我们过去的不足，甚至憎恨过去的技术选择，那正是成长的结果。
当然同时，也说明我们那个时候多么幼稚。幼稚，我并不是指经验少，而是指理
论太差。我们一般所说的知识，要么来自基本理论的演绎，要么来自经验的归
纳，别无他途。也正因为别无他途，所以一切新名词都是唬人的。而靠从经验中
归纳，你得活多少年才能有结果啊。所以，基本理论的修养，和从基本理论中经
过漫长的过程推导出结论来的能力，都尤其重要。
本来这只是回复你一个人的邮件，写着写着，痛感我们为幼稚啊什么的所付出的
代价，想着很多别人也可能有同样的经历，或者会有同感。所以，我把回信发到
博客里了。
>以上。保重身体！
请在集中开发中保重，这样过不了多久，你身体就会不如我了。
重申，一切不利于人类繁衍的规章都是扯淡的。
>老师，我因为工作原因又出差来集中开发了…
你总是集中开发，可真得注意身体了。岁数一大，就不如年轻的时候扛造了。
你对于技术的思考和总结，已经越来越有高度，令我欣慰。有你这样的讨论，即
使我在小山村里也不孤独。
>简述的是在2006年到2013年我接触的web开发技术路线变化。
你提到的几种技术，我的体会是这样的：
1.J2EE SSH 与 orm/sessionbean 它们都不矛盾，算是不同的方面吧。它们不能
比较，互相作为补充吧。
2.在你所讨论的角度上，web service 与 SSH 一样，都是一种框架 (或架构) 手
段，它们在软件工程上的原则是相通的，比如倾向于你提到的封装、抽象、约
定，只不过是在这些方面的实现机制和强调的程度不同。就像XP和RUP其实并无本
质不同。
3.no sql 和 mongodb又是与orm/sessionbean类似的技术方向，数据留存。
我的感想：1.框架(和数据留存)都有不少技术，它们无所谓好坏，而是有各自不
同的优缺点 (包括学习曲线的陡峭程度、现有人员的技术程度也算特点，要作为
采用时的考量)；工程师的责任，是针对具体项目，根据这些特点优缺点选择合适
合的技术。 2.如果不建立更全局和高度的观点来看待这些技术，是危险的。
4. 框架一直在试图解决一个问题，就是如何"约束"使用者的行为，而不是增加他
们的自由，以保证他们能够以更"正确"的行为使用框架所规范的底层机制，比如
语言。在一定程度上，框架的创造者们成功了。但是同时，使用框架真正的方
法，是理解和构造它们，而不是单纯被动地被约束。理解和构造框架，需要更深
层次的理论知识，更多地探索这些成型的框架的构造原则和动机。
5. nosql一类的数据留存技术，一直在试图解决两个问题。一是提高性能，降低
负载，采用的技术手段包括分布式 (集群、云，全算分布吧) ，二是与现有技术
的结合 (动机是方便程序员使用)，比如与OO的结合，比如脱离sql。性能和负载
方面，似乎卓有成效，而与现有技术结合的方向，一部分技术似乎有这样的目
的，即能让傻瓜程序员 (我指的不是那种KISS的S，而是受到培训很少，不希望投
入时间和精力、智力)也编程序。后面这个目的，早在COBOL时代就已经有了，无
论他们取得了多少成果，我仍深感怀疑。我怀疑的原因是，创造性的工作是所有
智力活动之所以有价值的特性，而创造性工作需要严格精确地描述--没有适当的
工具和训练，我不相信正常人类可以使用正常人类语言精确描述任何意图。计算
机又不是神仙，焉能知道你想得是啥，甚至很多人自己都不明确自己想的是啥。
如果自己也不清楚，就变成了希望计算机代为决定，这涉及人是否要放弃自由意
志了。
> 曾经以为走在软件开发的路上，必须不断地在自己身上增加各种砝码，针对于具
> 体技术的砝码。然后你的重量就大了，力量就强了。结果一边走一边发现有些东
> 西慢慢变成负担，又开始甩脱直到轻松，留下的是对于负重的承受力和感知。“在
> 任何一组东西中，最重要的只占其中一小部分，约20%，其余80%的尽管是多数，
> 却是次要的。”
确实，增加的东西，一部分只是暂时的奇技淫巧、眩目的名词，短期可能效果不
错；应该减少的东西，也正是这些。应该留下来的，是基础理论。而所有的新知
识，都应该建立在自己的现有知识结构之上，是现有知识结构的一个演绎结果。
如果突然来了些新名词，却无法用我们现有的知识解释，要么，那就是我们要变
更知识结构了，要么就是这些新名词是骗人的。变更知识结构的，我遇到过的情
况是读《计算机程序的构造和解释》， (1) lamda运算与图灵机等价，所以，这
是一套不同的思考方法； (2)这很接近于Johan Linus以前对我说的，物理或电子
出身的人难以理解"模型"，可能正是因为物理和电子工程师构造出的不是数据而
是物理模型，不是对问题的认识，然后建模，而是太早套用到了似乎唯一的既定
的解决方案上。这种什么跟什么是"同构"的，在《GEB》这本大书里有深刻讨论。
确认或猜想某个问题与某个模型同构，非常重要，因为我们可以选择一个更容易
解和对条件依赖更不那么苛刻的模型。
新名词骗人的，那就太多了，大多数新名词我都先归到这一类，如果不是一眼就
能看出来好的，等它著名了再说吧。
> 集大成的东西内部未必单一。平台级的产品，就应当能兼容并包多种形式、各尽
> 其能的模块或子系统，朴素的脚本是利器。这部分是联想到你设计的仪器软件平
> 台，以前没觉得是因为眼界小。
你这一段总结，让我想起了linux内核。这两天我配置linux内核，哗哗失败，一
次又一次。解决不了的困难，如同跟高手过招，屡屡被缠住，不要说攻击，连自
守都困难得很。不过，与高手同行，毕竟收获也很大--如果能幸存下来。linux内
核的结构，我看到的只是make的配置，正有点你说的这个意思。
我的另一个体会，针对你提到的"眼界"。这几天哪位同学来着，重提到一个问
题，研究了一六十三招以后，发现别人早就实现了。前几年Johan Lilius来长春
的时候，我请教他关于整个体系性能的问题，他给我篇论文，198X的。我看了以
后拍大腿，正是我想要的。另一个问题，我当时请教的，他从理认上否定了解决
的可能性。对198X年的论文，我当时提到，这多么令人沮丧，我们头疼很久的问
题，不仅有人解决了，而且解决了三十多年，而且，我们还不知道它已经解决了。
他说，你在博士阶段 (或者做科学研究) 所受到的训练，正是为了提高这种能力。
我们经常看到我们过去的不足，甚至憎恨过去的技术选择，那正是成长的结果。
当然同时，也说明我们那个时候多么幼稚。幼稚，我并不是指经验少，而是指理
论太差。我们一般所说的知识，要么来自基本理论的演绎，要么来自经验的归
纳，别无他途。也正因为别无他途，所以一切新名词都是唬人的。而靠从经验中
归纳，你得活多少年才能有结果啊。所以，基本理论的修养，和从基本理论中经
过漫长的过程推导出结论来的能力，都尤其重要。
本来这只是回复你一个人的邮件，写着写着，痛感我们为幼稚啊什么的所付出的
代价，想着很多别人也可能有同样的经历，或者会有同感。所以，我把回信发到
博客里了。
>以上。保重身体！
请在集中开发中保重，这样过不了多久，你身体就会不如我了。
重申，一切不利于人类繁衍的规章都是扯淡的。