恶魔和梦魇的私语------- 关于软件开发的务虚主义对话(1)

恶魔和梦魇的私语------- 关于软件开发的务虚主义对话(1)                                      序     恶魔吹着笛子来： 可能这不能算是一个序，仅仅是对于我在和mengyan讨论那么长时间以后的一些感受。我在网络上闲逛的5年中，我唯一碰到能够这么深入的谈论技术问题的应该也只有mengyan一个人了。我虽然没有亲自和他见面，但是我从我们的交流当中我可以看到他是一个喜欢”精耕细作”的人，很多问题也看的比较深入，这可能和我是一个巨大的反差。大家在看下面的文字的时候能够体会到这一点。至于争论，我想总是有的。我们想的未必是我们做的，我们做的未必是我们说的。“人从来就无所不知，但是却经常犯错“。Karl.Popper的这句话一直影响到我现在，但是无论是什么争论那终究还是猜想，最后总是要靠实践去证伪，下面的文章中大家也能看到我们的想法再不断的急剧的变动之中。其中很大一部分的原因在于 我们在不断的证伪我们自己的观点，从第一封信开始我就开始着手研究STL和还有后来的boost的源代码了。其中很多的猜想现在回过头来看看可能是可笑的，但是他们仍然是很有意义的。 我们私底下对gp,oo的进行过的一段讨论，其中还或多或少的涉及到了Java， com ，.net，gc,哲学，经济学等问题。我们得讨论远未结束，不过我们目前的讨论已经慢慢的转变了方向。 "Now is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning."（Churchill 1942）。 因为不是专著而是互相之间的通信，虽然我们两个都尽力做了修改但是由于我们工作都比较繁忙还是有很多杂乱的地方请大家谅解。不过我想这当中还是有很多不错的观点和信息但是就需要靠大家自己来挖掘和体会了。 梦魇: 应恶魔兄的要求，我同意把我们的部分信件公开。早在我还只是一个初学者的时候，就经常在网上看到恶魔的文章。钦佩之余，也想到，也许有一天，我会跟他发生激烈的争论。那时候的我还是不折不扣的学生，学生就是喜欢争论的，而我是特别喜欢争论的学生。这一年来，在我身上发生很多事，也改变了我很多，还是很爱说话，但慢慢变得不太爱争论了。偶尔会在网络上发发牢骚和感慨，大部分时候都了无兴致。每个人都有各自的观点，语言门派之争也好，设计优劣之争也好，未必有谁对谁错。我不是个很聪明的人，不善于预测什么，何必去以自己都未必确认的东西影响别人呢？又何必没完没了的争论呢？有什么想法，直接去做就是了，成功固然可喜，失败了也是收获。空发议论，有什么意义呢？ 在这个时候，这种心境下，居然还有人能够拉着我进行这么长时间和大篇幅的讨论，可能也只有恶魔兄能做到了。恶魔兄的知识面宽广，善于把握全局，同时有具有非常强的实际动手能力和学习能力，我非常钦佩他。下面的这些信件，是我们早期的一些通信，时间虽不久远，但是现在看来距离却已经不近。不光是因为我的心境和对软件的看法已经有了很大的变化，而且也因为我们现在的讨论逐渐已经转移到具体的设计问题上，所以现在读这些以前的信，多少觉得务虚而不务实。发表出来，只是想做个纪念，另外也许能引起一些网友的思考，那我们的目的就算达到了。 我还是不主张没完没了的争论，更何况这一段时间，我痛感自己实践经验的不足，希望今后能够扎扎实实地做一些事情，对于编程、软件的看法正在剧烈的变化，请读者不要因为我们的某些言论而耿耿于怀。你们未必错，我们未必对，大家各持信念，动手去做，这才是正确的态度。 ***************************************************** HI myan:   很高兴能够和你交流。看来你对c++是很有研究的。 我基本上同意你的看法：“ python的gp和stl的gp的实现思想是不同的”。但是我不知道，为什么你认为c++仍然是gp得主战场（当然我们排除c/c++比python得影响要广泛的多这个因素）。   在我的理解中template和gp作为一种编程的思想和方法其实是c++多继承的一个补救措施。Gp 的出现使得oo能够更加清晰简单正确的刻画世界 。 在真实世界中得事物描述可以用这样一种比方来解释:一辆汽车的轮子有轮子自己的运动的方式和功能， 发动机有发动机自己的的运动方式和功能，控制系统有控制系统的自己的方式和功能, 车子的骨架有自己的方式和功能他们互不隶属。 当我们组装一个车子的时候我们是把车子用多继承的方式去把这些不同功能的部件来组合起来。 oo作为程序设计思想本来也应该这样来做，但是c++由于多继承中出现了比较严重的语义歧义问题（比如典型的钻石型结构）使得多继承在实际的使用过程当中被刻意的回避。 不知道你有没有用过owl没有? owl是采用多继承的框架类库。但是owl采用了多继承以后导致了整个框架的不稳定，当初学习owl的document/view时候被多继承弄的头晕眼花。自那以后，mfc，vcl都不约而同的使用了单根继承的模型。 这样就在一定程度上回避了多继承的歧义问题。但是多继承好处也被抛弃的一干二净. 如果用单根继承的方法装配汽车的思路就变成了发动机，轮子，骨架，控制系统都是从铁原子 继承下来的然后铁原子用不同的形态转变成各个部件然后因为都是铁原子派生的所以能够在把他们组装再一起。这样车子是造出来但是我们的设计思路却变得的格外的怪异。为什么造汽车 非要从铁原子开始考虑。 Bjarne发明了template和gp这种独立于对象的思考方法。gp本身不需要对象的虚拟性的支持。它表现在于独立和单一但是他又能抽象的刻画事物运动的本质。因此我们 就有了强有力的工具用多继承的方法来从新规划我们的设计思想。也就是我们用gp刻画描述独立的事物 运动模型，然后用多继承的模式去把他们装配到对象当中去。tempalte和gp提供了一个我们把 轮子，骨架，发动机区别看待的一种理论或者说一种理由。 因此我觉得gp和oo的共性在于抽象，而不同之处在于oo强调事物的关联或者说是共性 而gp强调事物的独立或者个性。我们之所以感觉oo正在趋向复杂和混乱是由于我们没有gp这种强有力的工具。当我们有gp以后，oo的缺陷问题顺理成章得到了解决oo刻画世界的方式也就更加清晰和简单而不是牵强复会把所有的东西都看成原子的后代。观察mfc和wtl,atl之间的区别就能知道这两种方式的区别。     上次我们讨论gp和oo谈论到哲学，看到你的贴子觉得你的哲学素养还不错有点popper的证伪的味道。不知道你对编程哲学怎么看的我的感觉既不是科学也不是哲学是一种不伦不类的垃圾。     好了就谈这么多，已经很晚了。希望能够看到你的尽快看到你的信。 Ian.King 恶魔吹着笛子来: 这是myan的回信，这封信中的我们的意见暂时的统一在一起。 不过后面的争论就大了，在信的末尾我们讨论了一点karl.popper的哲学。 / SnowFalcon兄，你好！  我也非常高兴能和你私下讨论。因为现在项目的压力很重，所以我尽可能说得简洁一些。 首先，我以前是一个具有明显语言派系倾向的人。除了C/C++之外不把任何语言放在眼里。但是随着我对C++的了解越来越多，使用越来越熟练，现在反而能够从更高的角度看待语言这个东西，不再是一个语言主义者。我意识到，C++虽然是一种伟大的语言，但是缺点十分突出，很难培养出足够数量的熟练C++程序员。因此，在编程语言的发展过程中，也许C++的角色更像是一个开路先锋，未必能成为最终的主流。今天Java在OO领域中已经开始占据主流地位，在未来，这一幕一定会在GP领域中重演。因此，我对于C++在未来能够继续成为主要应用(application)开发语言的推论是倾向于悲观的。在1994年出版地The Design and Evolution of C++中，Bjarne Stroustrup就指出，C++设计时就没有打算作为大型应用系统开发语言。如果非要这么做，一是要有配套的应用类库，二是要加入GC(垃圾收集)支持。 那么为什么我还如此热情的投入到C++的学习中呢？因为我认为C++语言在现代编程语言的发展中，具有枢纽和里程碑的地位。就如同康德在哲学中的地位，是一座桥，你可以褒扬，也可以贬抑，但是在今后相当长的一段时间里，没有任何一个语言在设计、评价和讨论的时候，能够绕过C++不提。在面向过程、面向对象、泛型三个方面，C++都伸展到了一个静态强类型语言所能到达的极限，同时，还衍生出template meta-programming，并具有模拟functional programming的能力，它的博大宽广，令人叹为观止，Bjarne Stoustrup作为一个语言的设计者，他的勇气和胆量，实在很难有人能超越。所以，我坚定的认为，如果能够真正了解了C++，那么将来无论使用哪一种语言，都能够以更深层次的眼光看待之，不会被眼前的表象迷惑，不会失去方向。  在未来，我认为加入了泛型能力的Java/C#，正在开发的D语言，当然还有Python, 都有很好的应用前景。此外，我还看好Ada 95会有一定的发展，这种语言是除了C++之外我最敬重的语言。我曾经跟朋友开玩笑说，如果我开一家集开发、培训为一体的公司，那么我会教学生学C++，面向中小客户的开发和商业软件我会用Python和C++，而面向大客户的重要行业软件开发我会用Ada。玩笑而已，虽然不可能，但是倒确实代表我的一些基本看法。 至于GP，我曾非常乐观，但是现在的观点逐渐趋于保守。因为从概念上看，GP主要是对计算机算法和数据结构进行抽象的成果，也就是说，它对于计算机进行了很好的抽象，但是，这种能力很难拿来对现实世界作模拟。对于后者，OO确实是目前最合适的手段。而GP，目前技术上还没有取得关键性的突破，难以上升到方法学层次。倒是template meta-programming会对于OO有一定的影响。  对于你对GP的看法，我基本上是同意的。你应该注意到了，我从来没有把template看成是GP的必要条件。GP是一种描述，不管用什么手段，能够做到的就是GP。所以我对于java.util，JGL以及Python中的GP也并不排斥，相反我很感兴趣。但是由于template所提供的抽象方式非常独特，而且目前已经形成了一整套理论和支持机制，所以在这个方向上研究GP是最有希望的。否则Java也不会有了reflection还想纳入Genericity功能。 另外，对于今天的OO技术，我认为已经跟几年前的OO很不相同了。当初OO降临时，好像是个救世主，可以帮我们解决大规模软件开发的难题。结果呢，难题没有解决，反而带来了一大堆比原来更加繁琐的东西，还大大降低了系统的效率。所以现在出现一种变化，出现XP，出现Patterns，出现GP，出现各种模板库。OO也在以某种方式寻找出路。我觉得我们应该以一种鼓励的心态看待这种变化。从原始的意义来看，可能今天的OO已经偏离的方向，但是这种偏离是实践的结果，所以必须接受。因此，今天的OO不再是一种严谨一致的软件思想了，更多的只是一种象征，一种精神标志，一座偶像。 我曾经非常迷恋哲学，可惜放下了很长时间了。最喜欢的哲学家恰好是康德和波普。 谢谢你愿意在Python方面提供帮助。我确实有学习Python的计划。这个项目结束后，可能就会开始。到时候请多多指教。至于编程哲学，我不懂什么叫编程哲学。也不愿意参与任何有关这个问题的讨论。当然，我不了解，也就不能跟你一样给予强烈的抨击了。 孟岩  10-14