//////////////////////////////////////////////////////////////////
恶魔吹着笛子来:
这是我对myan的回信（注是〈关于软件开发的务虚主义对话(1)〉的最后一封信），里面表达了我对oo和gp的初步的一些想法当然还不是很成熟。
梦魇：
恶魔从软件开发成本来看待人们对开发语言和工具的选择与评价，确实是让我耳目一新，却又难以完全接受的观点。
////////////////////////////////////////////////////////Myan你好：
很抱歉那么晚才回复你的来信，这两封信我等待的很久(有点夸张:) )急切希望得到你对我的GP观点的看法。因为说道gp我也是门外汉 仅仅是这几天在csdn上参与你们讨论的时候才知道的。说老实话到现在GP的程序基本没有写过，
STL也仅仅是耳闻但是没有时间去学习。我仅仅从你们对GP和oo的讨论中逐渐摸索出一点粗浅的看法，所以急于想得到你这位GP专家的验证.当然我也很高兴我的看法能够得到GP圈子的专家的认同。所谓Python的GP其实也仅仅是我臆造出来的东西，在python中依然以ood/oop为主导没有gp这种说法也没有人这样做。我仅仅是看了你们对gp的讨论以后，联系到我正在学习的python突然来了一个灵感：python动态语义的功能或许可以实现 gp。但是我想了两天但是都是在类似于java.utily的继承兜圈子。后来我看到python
.org上有一片介绍Mixed_in技术的文章。这才让我豁然开朗只要利用python这种可装配类的概念肯定可以用python来实现一种别有风味的GP。所以由于python刚学所以编查资料边调试程序用一个晚上给你写了一个bubble sort的sample
你说你以前是一个语言主义者，很不幸在我大学二年级的时候我曾经也是语言主义者。 甚至可能比你更加低级，认为vc是最好的开发工具对mfc以外的东西都一概排斥。经过半年以后逐渐改变了看法，认为问题不在于那种语言更加先进仅仅是用那种语言实现成本更加低而已。我想成为一个语言主义者是一个程序员必然经过的过程。因为初学编程的程序员会投入太多的沉没成本(sink cost)学习语言的精力和时间的成本无法收回。当然sink cost越高越是能够阻吓新竞争者的进入(程序员) 。Bjarne不是说过么"我设计c++语言的目的就是要让程序员有饭吃".当新的技术新的语言出现使得sink cost越来越低，那么BBS上对程序语言的"文攻武卫"就会越来越多。
你说GP没有出路或者说出路目前还不明朗，但是我不 同意这样的看法。我觉得GP的出路目前 就很明朗。我想没有必要把所有的东西都变成万能钥匙。GP既然在抽象算法和数据结构上有独到之处那就应该让他在设计Componet&Module上发挥应有的功能至于描述世界那是oo的任务我们没有必要 无限扩展他的功能只要够用就好。我们应该记住，OO的混乱和繁琐最大的更本原因在于滥用。 用oo去写Componet就是杀鸡用牛刀。
在你另外一封信中谈到对目前oo江河日下的问题。我有两点看法
1． 这里删除200字（主要我觉得第一个看法大家并不能够接受也不一定看的懂）
2. 如果从需求定律的角度来讲oo的江河日下未必不是一件好事情。过去十几年ood/oop的设计开发成本一直下降，那就很容易推测，用oo设计和编写的程序的平均质量应该下降了。
ood/oop设计开发的成本原来非常高昂，粗制滥造的程序便没有回报。现在，不管需求大小，oo编程设计的成本都非常低，所以越来越多低质的设计和程序得以出现。这并非表示oo的能力下降了，而只是表明设计编写“较低劣”程序的成本下降了。设计编写成本下降的本身，使得所有类型的程序都增加了。不过，低质量和高质量程序编写成本同时下降，会使得低质的设计和编程的份额增大，因为现在设计那种程序有了回报。质量更低的东西让人们多了一些本来没有的选择，因为质量更低的东西，其价格也更低。应该说多一些低质量的东西，比
少一些低质量的东西更好。同时，质量更高的东西也更容易得到了，尽管高质量东西比低质 量东西的比例下降了。 今天OO良莠不齐，甚至江河日下的现象，从需求定律的角度来看，倒是一幅令人宽慰的图景。
另外你提到Ada语言，我以前也有耳闻。今天我到网上找了一下，时间仓促只找到了
sigada83的spec。看了以后我觉得ada的确是一个很优美而且很健壮的语言。但是我发现了
一个问题可能也是Ada不那么流行的原因，ada不支持类型扩展和动态编连（至少我看的ada83版本是这样不知道ada95有没有改进).我想ada的失败的原因大概就是在于此把。好了写着写着就发现写了那么多东西。希望不要有废话，也希望sina的服务器稳定一点好让我快点看到你的来信
祝好
Ian.King
/////////////////////////////////////////////////////////////
恶魔吹着笛子来：
这封信我把话题扯到java的gc上去了。 不过还给他起了一个绰号叫梦魇。是不是很cool呀。
///////////////////////////////////////////////////////////Hi 梦魇：
sorry你的中文名字在微软拼音里面出来了这两个字。第一我觉得很cool，第二我想不错恶
魔对梦魇的确满配(怎么像是Diablo哈哈:)).
今天我翻了翻你在csdn上的专栏，读了你几片文章。觉得你在c++/gp上的确是一个专家。但是当我读到<垃圾收集机制(Garbage Collection)批判 〉我觉得你是发射了一只射向java的箭虽然箭是有力的。但它都没有瞄准java的本质，所以只能呼啸而过。
你讨论的java的gc的弱点是只有程序空闲gc才会回收资源。
第一我不知道sun公司的那些人是怎么回答这个问题
第二我觉得在jvm的性能问题上sun公司绝对没有发言权他们除了夸耀 java在他们昂贵的sun服务器运行的如何好其他一概不知道。
我做过一段时间的java的performance tuning专门负责Java的Memory Leak(这个leak和你说的问题不同)。这个问题如果是我来回答的话.答案是这样的1.JVM的GC线程可以不中断程序运行2.Sun的JVM在性能上是比较差的他的内存回收算法存在着巨大的问题
第一jvm的gc线程的确不需要中断程序的运行采用-Xingc参数可以把gc的停顿时间减小，如 果你有双cpu你可以用xingc把gc线程挂接到一个空闲cpu上从而使得gc不中断程序运行。
第二Sun的jvm的性能是很差的，如果你采用ibm的jvm你就会发现他的性能是sun的三倍。而且基于ibm的独特算法它的jvm中的gc中断程序运行得时间比sun短5倍左右特别是在AIX平台 上ibm的jvm可以做到异步gc根本就不需要中断程序运行的功能而sun公司还只是在java1.4.1 的计划中提到异步gc功能。
java的gc一方面是解决了大部分memory leak的问题但是更加重要的一方面是防止内存的错误操作而宕机。Java的gc的确不是很成功，因为java的jvm和操作系统相互独立导致了性能的缓慢但是那仅仅是一个开端，随着.net的出现os捆绑Jvm的方案将浮出水面，性能越来越好 的gc将会出现.net的gc比java的更加灵活更加快速大概速度是java的10-20倍。
当然java不是没有memory leak，其实memory leak还是存在的而且java的memory leak的出现将比c++的memory leak，更为可怕，更为隐秘，调试的难度更大。其中 一个典型例子就是在一个生存周期很长对象中new出的内存在这个长周期对象中没有释放以前是不会释放的。
如果要指出java的缺点的话，在我想到可能有以下几点。
1。能够快速方便安全的建立一个应用，但是如果程序有严格的性能要求的话那么花在最后为 这个程序进行优化的成本将是建立应用的两-三倍
2。gc机制将导致程序员写出更加不严谨的代码，使得程序的性能大大降低。根据我的经验
java的80%的性能问题来源于程序员过于依赖gc机制而写出的低效率的代码因此我的观点是如果用java书写依赖于成型的服务器的插件(像servlet,jsp,ejb)的话,性能还是能够接受的。如果用java自己书写服务器程序的话需要花费很多时间去做优化。
Ian.King
//////////////////////////////////////////////////////////////////////////
恶魔吹着笛子来:
以库的方式实现gc，我想这是对我认识的一个比较大的转变。后来仔细审查boost中的share_point和stl的auto_ptr的代码感觉到的确这是一个即安全又高效但是又相对简单的方法。但是我个人比较
偏爱auto_ptr原因是实现比较简单。
梦魇:
除了std::auto_ptr之外，boost库中提供了scoped_ptr和shared_ptr。有了这些智能指针的帮助，我们在程序里能够避免绝大多数资源泄漏问题。但是，仍然对于程序员提出了很高的要求。
//////////////////////////////////////////////////////////SnowFalcon兄：
你好！
看了你对Java GC性能的分析，非常钦佩。我对于JVM没有实质的认识，那篇文章是从网上看到各种争论后总结而成的，偏重原理分析，而纯理论的推论，在实践数据面前，肯定是苍白无力的。事实上，有一点可能你不知道，对于资源问题，我一直是赞成GC解决方案的。因为如果GC设计的好，其性能应该超过基于reference counting的smart pointer。但是我的观点是，GC必须是可控的，召之即来，挥之即去。因此，我赞成以库，而不是核心语言的机制来呈现GC。目前C++正在着手处理此事，boost.org中已经有个一个标准多线程库。相信在200X版C++中，这个问题会有比较好的解答。
其实我写这篇文章，倒不是说要打击Java。只是就事论事。Java如此缓慢，长此以往，是要吃大亏的。宣传攻势可以成功一时，却不能长久。围绕Java和.NET的泡沫实在太多了，以至于我现在根本不愿意去过多的谈论他们。还是等泡沫散去，在行评论吧。我并不打算去追逐风潮。事实上，我的观念里一直有一种逆反思维，当所有人都冲向一个方向时，真正的机会往往在另一个方向上。所以我跟你谈到Ada，这种语言适合于开发极为可靠、高效率和长寿命的大型系统和嵌入式系统。我觉得这恰恰是未来中国软件市场上一个重要的需求。只可惜现在我没有精力分心出来系统学习，而且恐怕也很难找到足够的Ada学友。
看了你的几封mail，的确有很大的启发。比如你提到Java GC机制对于程序员的纵容，谈到OO的滥用，确实切中要害。我现在越来越觉得，纯技术在实际软件开发中的作用是有限的，技术人员的素质和团队的管理，实际上远比技术重要得多。你从经济学的角度分析软件技术发展趋势的思路，也是非常独到的。希望更多地听到你的观点。这个星期我非常繁忙，到下个星期一，会告一段落。到时候希望能再和你好好谈谈。我希望能帮助你更多的了解目前存在于C++中的GP实现机制，然后由你从自己的独特视角分析一下这个方向的发展趋势和前景。
孟岩
10/19
//////////////////////////////////////////////////
恶魔吹着笛子来:
给myan的回信，这封信说的是一些题外话。
/////////////////////////////////////////////////Hi梦魇:
这个礼拜空下来了吧？看了你上个礼拜的回信感觉比较匆忙，为了便于我们的互相
讨论我还想听听你对我前几封信的具体的意见（主要我对GP,OO的发展方向，以及一些
其他的意见比如ood/oop的转型问题) 同时我希望你能够介绍一下GP的发展方向和目前的存在的一些问题，以及一些你对GP的内在处理机制的看法。
你说"GC必须是可控的，召之即来，挥之即去”那我想.net中的unsafed代码应该能够满足这样的需求。不知道除了这种方式还有其他更好的解决方案。另外最近我也想过，通过追加类似LifeCycle的关键字来定义内存的生成周期的方式来解决gc的问题，但是这样和delete的方法没有任何的区别。
你谈到经济学，经济学和科学哲学是我目前除了Computer Science 以外最感兴趣的两门学科。对Popper开创的科学哲学对我的方法论有很大的帮助，芝加哥学派的新制度经济学是我认识世界的认识论的一个标准。经济学往往被人误解为模糊的学科，或者是与金钱打交道的学科，但是我的认识中经济学是解释人类选择行为的科学。他不仅仅解释货币，企业的供需问题。更加重要的是他解释了人类选择的行为，只要人类那里有选择，那里有能用经济学来解释，比如婚姻，忠孝，雷锋精神和利他主义。我对IT目前的一些看法往往都是从这个方面去考虑的，比如为什么对于中国大多数企业来说软件工程是没有帮助的，为什么软件质量的江河日下是一个令人欣慰的图景，为什么网络经济是在胡说八到，为什么linux没有出路。赫赫当然答案并不是所有人甚至是大多数人能够接受的。
真想和你能够面对面的聊聊，email的过程太慢，如果你有ociq或者mirc之类的聊天
工具，我想我们的交流可能会更加深刻。
谢谢。
Ian.King
本文地址：http://com.8s8s.com/it/it2822.htm