/////////////////////////////////////////////
//
恶魔吹着笛子来:
这封我对myan的回信，详细说明了我对gp,oo,开发工具，软件实现的关系。
另外我对c/c++目前的现状发了一顿牢骚，但是我说的仅仅是结果而非原因。 关于
世界3的讨论后来不了了之，原因在于这个问题本身就不成熟，另外也没有什么指导
意义。但是其中一部分成为我们后来达成的一点重要的共识，那就是gp目前还是应该
在Component设计领域中，在软件设计中应该严格限制gp的运用。
梦魇：
对于GP的作用和地位，我的观点在不断变化中。有的时候评价过高，有的时候评价过低。其实对于现实工作来说，评价是次要的，关键是要能用。在这一点上，恶魔兄是个不折不扣的实践主义者。今天再来讨论template的效率问题，我想恶魔兄会另有一番体会。
////////////////////////////////////////////
你好。收到你的来信已经好几天了，我迟迟没有动笔给你回信。因为我需要更多的时间和
收集更多的资料来理清的思路。 即使是今天我写这封信的时候我对我自己的想法还没有太大的把握。
你上次的来信中具体的描述了GP和Template的实现和优点。你说GP不是oo的补充，我觉得 不正确。但是我以前说GP是oo的补充，也不对。 你在讨论GP的时候将GP和template对编译器处理的混在一块讨论，把编译器编程的优点赋予了GP而推导出"基于Template的GP更加先 进和优越". 我觉得这样的一种思考方式不正确。你曾经也说过GP不一定要template 来实现。
我认为GP是一种设计模式和，oo的模式在同一个级别，而编译期处理是一种编程实现
模式。就像我们不能把java中gc这种功能的优点算到java的oo模型上一样。我们只能说java 的gc功能将能够增强java中oo模型的使用性和实用性而不能说由于有了gc所以java的oo更加 优越。
你熟悉karl.Popper的理论，那我想你也应该熟悉karl.Popper的世界3的理论。我有这样
一种猜想就是:我们也可以用世界3的模型来说明软件设计学（但是我这个世界3和Popper的世界3并不一样)。
世界1:现实世界的需求
世界2：设计模型和模式（例如GPD,OOD,Design Patterns ,等)
世界3:实现模型和模式（例如oop,Template,GC，Mixed_in）
对于世界1我们可以这样来理解，世界1中存在着这样三类元素
1.一系列的基本元素，他们是组成世界1中其他事物的基本元素可以把他们理解成对象。
他们有独立性，独立性可以描述一个基本元素和其他基本元素之间的差别
是A就是非B。如A=Book那A!=Desk。
他们具有衍生性，衍生性可以将符合基本元素特性的一些列事物看作是基本元素的衍生便于
抽象和归类。
A=历史书->A=书
2.相同元素之间的相互作用关系，他们使得相同的基本部件之间的相互作用关系抽象化，成
为构件世界1的又一个基本元素。
他们有对相同的基本元素有广泛的通用性和单一性，如BookSortByName可是适用任何Book及其衍生物但是对于Desk和Desk的衍生物却不适用。
3.不同元素之间相互作用关系，他们是使得相对独立的基本元素之间能够互动形成我们
需要的应用。
例如，Book on Desk,
世界2 我们可以这样来理解他们，他们是一系列的描述工具。我们可以用他们来描述世界1中的三中基本元素便于我们更好得理解世界1。你可以看到世界2中的内容我没有说OO或者GP而是说GPD(Generic Programming Design),OOD(Object Oriented Design)。
因此我对我上次的观点"GP是OO模型的补充特别是对多继承的补充"持否定的态度。
GPD,OOD仅仅是设计模型和模式的内涵而非就是设计模式和模型这个范畴的本身。
我想更加精确的说GPD是对设计模式和模型的一种补充。
世界2中的描述工具并不一定和世界1中的元素们一一对应。仅仅是我们选用最合适成本最低的描述的工具来描述世界1。仅有OOD不能够有效的描述完整的世界1，用他来描述元素1OOD非 常适合但是用它来实现世界1中的元素2会出现不必要的冗余，繁琐。仅有GPD也不能够有效的 描述完整的世界1，因为用它来缺乏对世界1中的元素1，3的描述能力。 是不是有了GPD和 OOD就能够完整的描述世界1，我不知道。我只是知道到目前为止只要GPD和OOD就足够描述世界1了。
世界3，他们是一些列的实现工具。我们可以用这些工具来更具世界2中的描述来近似的实
现世界1的情况。 同样在世界3中，实现工具未必要和世界2中的描述工具一一对应。例如我 们可以用OOD来描述世界1，但是在世界3中我未必要用oop的方式来实现我可以用面向过程的 方法来实现仅仅是用面向过程的方式我要定义更多的数据和结构。选取什么样的工具仅仅依据实现成本而非实现工具本身。
同样实现世界2中的GPD可以用很多工具来实现，比如Template,oop,Mixed_in等等。
我认为从技术和效率上来说c++的Template和python的Mixed_in显得更为优越或者说的通。
Template，能够比OOP的动态类型鉴定来提供独立的算法模型和更加高效代码。而Mixed_in
从动态改变类的继承树方面降低类层次结构和独立算法模型。用模版Vector<T>可以适用任何对象，而不必为每个对象都建立Vector算法。用Mixed_in我们可以在任何时候为任何对象继承Vector类或者删除Vector类。这两种技术有异曲同工之妙。只不过一个可以对c++的编译器编程，而另外一个是对python的解释器编程。但是从效率上来说Mixed_in还是稍逊一筹。
从经济学的角度或者说从实惠的角度来说，我仍然认为Template不是一个好产品。他也不可能胜出。我先撤远一点，……（这里删除200字主要讲述了路径依赖的一些问题。首先可能撤的太远不便于读者阅读，另外可能读者也不一定接受这些观点）
话在说回来从实惠的角度上讲我觉得Template和Beta录音带一样是一个次等的技术。
Template的首要目标是效率其次才是GP编程。但是效率对于一种技术来说仅仅是一个方面
他并不起决定因素。Tempalte的缺点在于语法的复杂性。大多数的用户未必都会性能要求很
高，他们并不是作学术研究的它们需要对口袋里的银子和性能进行衡量。
提高性能，必须要提高成本。这是无可避免的。对于大多数的性能要求不是太高的应用的程序开发（如Desktop 应用），有两种方案一种就是在编码时采用c/c++语言,template但是付出的成本是昂贵的人工开发周期的延长，得到的结果是实际性能要比用户能够感觉的到的要好，第二种方案是采用容易语言编码缩短开发周期和人工但是需要付出性能不够高的代价，但是他可以用节约出来的成本的一部分来把程序优化到用户可接受的程度。最终在性能优化上面两者都提升了成本，而结果两者得到效果在用户这边看来是没有任何差别的。但是高昂的人工开发商承受不起，过长的开发周期用户的等待不起。在供需两方面来说牺牲一些性能都是很值得的。市面上大多数应用例如Mis系统都是如此，甚至大型的商业应用采用Java,perl的也越来越多。另 外高端的应用应该是c/c++的领域但是现在越来越多的用得都不是c/c++方案。如电信行业。我们公司目前一直在和电信打交道，我们给电信作的方案是100%的pure java.我们了解下来 其中主要的原因在于电信行业竞争越来越激烈，电信提供商如果错过一个业务的发展会丢失 很大一块市场份额。而Java应用的开发要比c/c++节省40%的时间和30%的成本他们电信运营 商宁愿用这些省下来的钱去买高档的服务器也不愿意等5-6个月的开发周期。不仅仅是我们这 样做，连IBM,Lucent目前主推的Call Center或者电信平台都是基于Java的。另外一个高端 领域:Web服务领域c/c++市场在快速的萎缩而性能较低的方案asp,perl,jsp却统治了90%的市场。
为什么这些年来大家都宁愿舍弃高性能的C/C++而大量采用编程方便但是低效的解决方案。我想这是应该是c++的设计者应该迫切考虑的问题。因此从我的角度看Template从技术角度来说是一种创举但是从实惠的角度来说的确是一种次等的技术。
谢谢
Ian.King
/////////////////////////////////////////////
//
恶魔吹着笛子来:
梦魇在这封信里火气很大。当然不是冲我，而是冲着c++目前的现状。梦魇看来是一个敢于做事而不是靠着抱怨过日子的人。同时他也是一个喜欢深入问题的人，而对于我来说正好相反我是一个喜欢不求甚解，只求自己的脑袋得到快乐的人。另外，我至今还是保留一个观点：并不是c++教育的问题导致了目前c++社区的怪装，而是c/c++本身的问题。最主要的是c++延续了c的特性，使得很多使用者长时间停留在c的设计模式上。当然从这封
信里我们看见c++社区已经在努力摆脱c的束缚形成了自己的一套体系，当然c++的教育
将在这个问题上大有危机也大有作为。
////////////////////////////////////////////
SnowFalcon兄：
抛开哲学的问题不谈，我认为你单方面认为template开发成本高，这是经不起考验的。Template本身就是为了避免重复开发而设计的，它的出发点就是减少重复代码的编写，提高开发效率。使用template设计的库，比如STL，Boost，可以大幅度的降低开发中的重复劳动。至于复杂性，这更多的是人的习惯问题。我周围有很多C++的爱好者，他们都能够纯熟地使用template语法。相反的，如果让我来写Python的GP，起码目前我觉得非常蹩脚。
C++开发效率相对较低，这是事实。但是你把这归咎与template语法问题，这就是天大地冤枉了。事实上，如果更多的人使用template，可能会为C++挽回一些声誉。为什么你会得出C++的开发效率很低呢？当然是从身边的实例中得到的印象。为什么大多数C++项目都显得开发效率低下呢？原因很多，工具的缺乏是一个，另外，通常用C++做的项目本身难度就会比较大。但是这些都不是我所关心的，我认为现在C++社区必须致力解决的，主要是两点，一是C++的教育，一是C++类库的匮乏。
几年前，C++是整个产业的宠儿，现在，成了不少人侧目的反派角色。是什么损害C++的生命力？所有原因中放在首位的，是C++的教育不利。几乎所有的C++教学，都把C++当成C的一种扩展，一上来就讲那些低级的知识，这样培养出来的程序员，即使了解了C++的全部能力，在他脑子里整天盘旋的，还是指针、动态内存这些低级的东西。试问Python程序员什么时候需要考虑内存释放问题？一个整天考虑这里内存会不会丢失的程序员，他的效率怎么可能赶得上Java/VB/Python？说道这里，你可能会反驳：“但是C++本身确实需要考虑内存回收问题啊！”。事实上，NO！使用STL和Boost库，我真的可以一个delete都不用，一个字节都不泄漏。而且写出来得代码很清晰。遗憾的是，整个C++教育界都认为这是高级C++技巧，从来没有人一开始就告诉初学者“你可以这么做”。包括我在内，很多C++使用者整天殚精竭虑地在想：“这个函数应该返回一个字符串地拷贝呢，还是传回一个引用更快？”更有甚者，C++程序员中一些学院派整天还在争吵shared_ptr多占用的那几个时钟周期！老天，都什么时候了？！ 那个功夫，Java程序员又完成一个项目了！
C++发展了21年，从一开始就希望让它的使用者能够避开C中的那些低级操作，同
时 又获得与C极为接近的效率。然而，就在我们终于有这个能力的时候，那些糟糕的教师
和书籍却还在教着什么malloc和free! 没几个人关注如何让初学者使用上C++年发展的
成果，如何把C++当成一门跟Python、Java类似的高级语言来使用。
现在你明白为什么我们C++编程者效率低下了吧，我们整天在考虑Python/Java程序员做梦都没想过的问题！而这些问题本来我们也是可以，而且应该不考虑的。这一状况已经严重的威胁了C++的生存。如果C++的教育状况不获得改善，我对它的前景十分悲观。
为了向你说明问题，我可以简单的罗列一些现代C++库已经具备的一些能力：
※ 可以通过使用auto_ptr，smart pointer杜绝资源(不光是内存)泄漏问题。
※ 可以用一行代码生成固定大小的数组、动态数组、堆栈、队列、双段队列、
优先队列、堆、集合、有序映射表、无序映射表和图。
※ 可以使用同样的代码访问各种不同的容器。
※ 有一个设计得非常出色得string，而且可以轻易支持国际化。
※ C++ IO流类库可以抽象所有的数据输入输出模型，而且其设计极为精巧，只要
自己动手写一个stream_buf类，就可以用同样代码对各种数据流实施透明访问。
同样的功能，在Java中你得记住十几个类之间的相互关系才能做到。
※ 使用Blitz++, C++高速数值计算能力已经超越Fortran。
※ 并行数值计算能力无疑伦比，这点在POOMA、Blitz和MTL库中得到体现。
※ 基于TAO/ACE的C++网络层提供了非常出色的网络计算环境和CORBA实现。
※ 有一个基于template的可移植高效线程库(刚刚出现，还需要完善)。
※ 有及其强大的正则表达式功能，非常容易使用，而且效率非常高。
※ 可以完全精致地控制内存地使用，轻松的建立自己地内存池。
※ CRC冗余校验
※ 数据压缩存取
※ 将若干异质对象看作一个值(类似Python中的元组)
是不是让你很惊讶，其实只要用几行代码，在C++中你能获得比Python还要多的东
西。 而且效率非常高。可是你见过能够熟练使用这些facilities的程序员吗？起码我是没
见过。为什么？因为我们把时间都花在如何操作指针节省100个CPU时钟周期上了！
这还只是开始呢，在未来的几年中，C++会大刀阔斧地增加标准库和准标准库的涵盖面，包括数据库、网络、CGI方面等都会出现优秀的C++库。如果我们的教育能够跟的上，C++完全可以在开发效率上接近Java。但如果我们的教育跟不上，那么结局就只有失败。
就说这么多吧。关于FP，你可以到网上查一下FC++库的信息，相信你会得到满意的结果。
/////////////////////////////////////////////////////////////////////
//
恶魔吹着笛子来:
对于下面两封信，我想我没有太多可说的。你可以从不同的角度来理解他们。我仅仅
是从我习惯的角度—经济学，来讨论问题。可能作为程序员的读者可能并不会很喜欢。但是有一点myan对于c++社区的确比我要熟悉的多。他的观点对于大多数程序员读者来说
可能会有更大的益处吧
///////////////////////////////////////////////////////
梦魇：
你好，看了你的来信。相信你的火气比较大。就你来信说明的几点问题，我仔细的看
了。在的信中提到下面几点:
1. 工具的缺乏
2. 项目本身难度
3. C++的教育
4. C++类库的匮乏
我说过，虽然经过几天的思考但是我回信的把握不是很大。看来我的估计是正确的。我向C++射了一只箭，虽然这只箭并非有力，但是我相信我仍然射中了靶心——如果从实惠的角度上来说，至少目前C++是一个次等的产品。虽然不能全部归咎于Template的语法，但是你的4点问题倒是给了我四只更加强有力的箭(同时我仍然坚信复杂的语法和过高的学习曲线是这个四个问题的根本原因)。这四只强有力的箭足以让c++退出目前大部分的市场。我并非对C++有任何的怨恨，只不过市场和客户的选择是我们不能左右的。市场上的产品全然是由客户投票决定的。只不过客户用自己口袋里的银子投票而已。客户门投了Java一
票而不投c++的票本身就说明c++自身的问题相当严重。也许从技术的角度来说你列举的例
证：大量正在丰富的类库，友好的内存管理等等是先进的，但是只要客户觉得不实惠那就说
明他们不完善，不好用，不符合市场的需求，不符合客户的需求。
你提到C++的教育问题。你说” 事实上，如果更多的人使用template，可能会为C++挽回一些声誉。” 我想你的想法可能仅仅是一种童话里的故事。我要问为什么目前那么多人不用Tempalte?你归咎于C++的教育问题。那么你有没有想过教育也是客户投票的选择。C++,Java都是美国人发明，那么技术资料语言沟通的问题应该相当。不会存在Java的资料多容易寻找而c++的资料匮乏，Java是sun公司的产品在市场的推广上来说sun,ibm,weblogic等都是化巨资的，而c++也不会差Borland,微软，IBM，甚至Sun本身也投入巨资（最近MS还请了Stanley B.Lippman加盟C++工具的开发）来进行推广甚至因为微软的抵制Java的应用推广范围还不如C++。那么为什么C++的教育如此的不利呢？我想还是不实惠的缘故，教育也是一个市场。学习是需要投入成本的，投入同样的成本回报高的自然就流行教育体制就好。
你说”虽然C++有比delete更好得内存管理办法但是C++的老师和学生都在纠缠内存释放的问题“。我要问为什么。仅仅是习惯的问题吗？回答是否定的，习惯可能会产生一小部分的影响，关键是这些东西的学习成本太高了你要懂得这些东西必然要熟悉模版，扩展库功能大量应用。你说: “至于复杂性，这更多的是人的习惯问题。我周围有很多C++的爱好者，他们都能够纯熟地使用template语法。”我们不能用专业人员的眼光来看初学者，专业人员他们即使原本不是学C++的但是他们已经为计算机的理论知识和实践经验付出很多的Sink Cost，对于C++他们要付出的学习成本要少的多。我小时候为学习拼音的已经付出了4年的成本。我现在用拼音输入，效率虽低，却无须重新学习。五笔打字虽然效率高，但必须投入两个星期的时间来掌握。我花不起这么长的时间。所以到现在为止，我还是用效率较低的拼音输入法，我感觉这更经济合算。从一个非计算机专业初学者的角度出发要熟悉C/C++的指针，OO模型的运用没有半年到1年的实际运用是无法想象的。他们学了一年的C/C++的选修课我和他们聊C/C++他们除了printf,scanf简直就是一个满不懂。Java的GC几乎不需要学习者花费的成本对于初学者来说仅仅只要知道Java会内存回收就可以。这种诱惑是不可低档的，是C++所不能比拟的虽然从我的技术角度看来是一个Java的GC是一个愚蠢的想法。
你说:” 几年前，C++是整个产业的宠儿，现在，几乎成了人人侧目的反派角色。”如果从需求的角度出发。现在软件开发人员的需求越大，那么软件人员的价格也就越来越低。如果一个软件人员需要投入1到半年的时间来学习C++但是出来他们的薪水只有3000-4000块，他们肯定觉得不划算。因此学习C++的人员必然把薪水开的很高6000-7000。但是软件公司特别是中小型的软件公司负担不起这样的高薪水。就是如同印度那种大型的软件公司由于越来越专业化形成软件工厂需要的不再是软件百领而是价格便宜的软件蓝领。他们就专向那些学习成本能够为快速公司开发产品但是薪水低的人员。那么Java vb,delphi就大行其道。C++的冷落和Java vb delphi的兴起对于C++程序员来说是一个悲哀但是从市场需求的角度来看却是一个好现象他降低了软件开发得成本，使得软件更加便宜更加容易开发为社会带来更多的财富。
你说:”为什么你会得出C++的开发效率很低呢？当然是从身边的实例中得到的印象。”我给你讲一个小故事: 我们可以向物理学家费米学习，靠直接的感受，得出与精密测算媲美的判断。1945年第一颗原子弹爆炸，当冲击波来到费米所在的掩蔽处时，费米向地面撒下一把纸屑，他根据纸屑吹落的距离，很快说出了原子弹爆炸的强度，其结果与精密仪器测量计算的结果非常接近。我们不妨审视一下我们的真实生活，你也许看到过装防弹玻璃的高级轿车但是你永远不会看到装防弹玻璃的拖拉机，你肯定看到过34寸的彩色电视机但是你永远不会看到34寸的黑白电视机，同样你可以看到铺天盖地的Java认证但是你绝对看不到C++认证考试有那么欣欣向荣。我还是那句话技术不是决定性的市场的需求才是决定性的。技术的走向必须依从市场的选择。现在因该是C++的设计者们乃至整个C++社区都应该审视C++的严重问题。希望C++不要像Ada一样落到是一个先进的语言是其他语言设计的借鉴典范但是在从实惠的角度讲却是一个次等品。
Python的问题其实和C++一样严重，我现在也在为Python的前途主要在中国的前途担心。另外你列举了很多高效能的类库说”是不是让你很惊讶，其实只要用几行代码，在C++中你能获得比Python还要多的东西。”你好像又说偏了，其实Python的功能类库远远比目前C++来的多从数据库，Web/CGI,3D图形，数值计算，乃至人工智能并行处理都有很多好的类库。同样我也只要写一行语句就能实现你说的功能。但是Python这些东西都是要归功于C/C++来编写那么多丰富的类库，Cpython的发展与C++是息息相关的。
谢谢.
Ian.King
恶魔兄：
你难道是一张弓吗？为什么把能拿到受的东西都当成箭呢？ :-)
我在写上一封信的时候，确实有一些火气，但是并不是冲着你。而是针对目前国内C++学习者现状而发。我原来是想写一篇文章，抨击现在C++社区中的一些不良现象，正好你的信到了，我就把自己的思想向你透露了一点。不过现在 我已经打消了发表这篇文章的想法，因为我目前有工作在身，只能说，不能做，没什么实际意义。
其实说心里话，我真的不但心C++会衰落，原因很简单，C和C++是整个工业的基础。我们现在所能够用到的几乎所有民用软件，从操作系统到数据库，从TCP/IP协议到COM/CORBA组件模型，从编译器到浏览器，从办公应用软件到高速科学计算，到处都是C和C++。目前他们不占据统治地位的，只有三个领域，一个是Web，一个是军用高可靠性软件，还有一个是科学计算。军用软件，自然有Ada撑着，看起来还有中兴的意思，不过我认为相当长时间里不会对C++构成实际威胁。科学计算领域，Fortran已经被C++打得摇摇欲坠，Fortran的发展已经接近停滞（虽然最近还推出一个Object-oriented Fortran，但是响应者寥寥）, 而最近几年美国高校和科研所中的科学计算，C++是个强劲的趋势。唯一C++感到比较吃力的，是Web。恰恰Web又是现在最红火的东西，所以包括你在内的很多人得出C++ 不行了的结论，未免目光太局限了。话说回来，Web方面C++也不一定就不行。这方面我们尽可以走着瞧。
我的时间实在不多，所以只能就几个问题给你简单的答复。
1. 你认为C++不实惠，我同意。如果1980年你就能意识到这一点并且说服整个世界建立在 Ada或者Pascal基础上，我们都会好过得多。可惜太晚了，现在有计算机的地方就有 C和C++。你想推翻重来，已经不可能，因为那是最大的不实惠。
2. C++是不是注定很难学。原来我也是这么认为。我付出了4年的艰辛汗水，才感到入门。 但是现在我认为，一个没有学过任何编程语言的人，只要智力正常，在半年到一年的时间里，通过正确的教育，完全可以在写应用程序方面超过我。尽管可能对很多语言细节还不十分清楚，但是他们能写出高效、清晰、安全的代码，构造强大的应用程序。这一点Babara Moo和Andy Koenig的教学实践已经证明，他们的Accelerated C++ 正在改变C++的教学思想和面貌。我本人也打算为此做些工作。你会看到一些实际行动的。
附带说明一下，防止资源泄漏的技术不需要付出很高的学习代价，轻易可以学会。 你只要记住在想使用指针的时候，把
TSometype* p(new TSometype());
改写成
shared_ptr<TSometype> p(new TSometype());
再学习几条相关的规定，就行了。你可能觉得用户还得先学模板，好烦。但是我要 告诉你，正确的C++教育应该在第二天就教模板。所以当他学到指针的时候，模板早就在在心里扎根了。我曾经对一个完全不懂编程的人介绍算法和模板的思想，让我感到很惊讶的是，他觉得模板的思想非常自然，很奇怪为什么计算机界把这视为是高级的东西。至于语法，我也希望简化，但是我也认为，即使不简化，普通人也可以轻松地学会基础语法——只要教的方法正确。
3. 客户们不投C++的票吗？那只是你的世界。我这里到处都是C和C++。别忘了这个世界不只有Web，更别忘了Web是站在C和C++的肩膀上的。
4. 关于Java。我很喜欢Java，也比较熟悉它。我喜欢Java是因为它在OO设计上优于C++，是一种严肃的编程语言。包括Python，C#，我都有很浓厚的兴趣，因为我相信它们都是严谨设计的语言。但是好像你喜欢它们的原因不同，你觉得使用它们可以进行快餐式开发，所以它们很出色。这反而让我对它们的前景非常忧心。我知道你希望软件开发成本降低，可是如果因此连质量都不顾了，恐怕在任何一条经济学理论里也行不通吧。我现在已经有点感觉，似乎编程语言市场也有点变得象普通商品市场一样，要分高档货和低档货了。象Ada和C++这样的高档语言，可能在将来的任何一个时代都不是占有率最高的，但是其品牌却长期有着不可动摇的地位。而如果Java不幸被归于低档语言，那么不论其兴盛的时候有多么风光，都可能会很快被别人打下台。低档货的市场不就是变化快嘛！你瞧，C#已经来了。别急，还会有后来者的。
5. 你好像是印度软件模式的崇尚者。这个问题我不想展开来谈，不过印度模式的成功，绝对不是快餐软件的成功。我想你也不会这么认为。国内对于印度模式的宣传，乃是根据软件业领导者和管理者的有色眼镜，有选择的作出报道与评论，根本不是印度模式的全貌。作为一个小小的反驳我给你举一个例子，最近Herb Sutter在网上开高级C++课程，费用昂贵，但是印度是除美国本土之外，参加人数最多的地区。以至于为了照顾印度的时差，还特意对课程的时间做了调整。可见，人家并不是想我们想的那么功利。
6. 最后，你说Python的资源比C++丰富。不知你做过调查没有，有没有统计数据。从Bjarne Stroustrup 的主页上你可以找到大量链接，其中有些链接本身就是链接库，如果你有兴趣坐一下调查，可以 从这里开始。 www.research.att.com/~bs 关于市场与技术之间的关系，我当然不认为技术决定市场，这未免太荒谬了。但是说它们之间的关系是市场决定技术，则恐怕过于简单化和武断了。
至于世界3理论，我会考虑一番再说。不过，我对于这种层次过高的东西没什么太
大兴趣。上次跟你谈到过，越是接近真理，越没有用。
/////////////////////////////////////////////////////////////////////
恶魔吹着笛子来:
这里删了若干封信，原因是找不到了。另外我觉得这几封信基本上都是围绕着c++的定位
和前途来说的，但是上面两封信我想基本上已经说明了问题，下面这几封的讨论基本没有
什么太大的改变。因此为了不影响读者的思路我认为还是删除为好。
///////////////////////////////////////////////////////
。。。。。。。。。。
