/////////////////////////////////////////////////////////////////////
//
恶魔吹着笛子来:
10份我去了一次Seattle的MS HQ，和myan做了一点.Net和GJ的讨论来打发旅途上的寂寞。当然mengyan还是很“关心”我的考虑到我紧张的出差他就没有会信直到我会到上海为止。（下面有一个阶段的信都是英文的原因是我没有中文系统）
梦魇:
///////////////////////////////////////////////////////
HI myan,
Are u all right? Sorry,I am at Seattle now.These weeks,I am busy
working in Microsoft so canot keeo contact with u.Next week I will go to
Santana.Have u recived my mail?I'd likelook foward ur guidiance.
By the way,in the future,Python will be added the static-type checker.But
It will be optional like VB and It will support Dynamic Parameter(just is
template ).
Yours Sincerely
Ian.King
HI myman:
Now I have gone away from ms HQ.The airplan are being checked for half
a hour.So It take the only free time to write this letter for u.
There are much pepeol developing VS.Net platform at MS PG(Product
group).Yestday noon,I talk about generic with them."Will u wanna add the
template in .Net?","Yup,The version two will support it.but it will be
optional"."How u implement it?Type-Checking at compiler time like
c++?","No,We have our own technology,it is more powerful than c++"."oh?
What's it?""Sorry that 's confidential.But u can research the gj(Generic
Java).Generic of C# is similar as GJ".
I download the gj from http://www.research.avayalabs.com at the nigth.
I look into it and it's document.I am very exciting.The GJ team have
already released the GJC(Generic Java Compiler) for Java2 platform.It
support almost all over Template syntax beside template customization.
I am interest in the mechanism of it.I use NMI to decode the class file.
It become very despaired.If u look into my attachments,u will know what's I mean.The GJ is a mask of OOP.They are cheating.If the generic of C# is
implemeneted by the mechanism as same as GJ,the cheating will go on.
Sorry ,I must shut down my computer because of the airplane will take off.
I will keep contact with u.Thank u! Good Luck!
yours sincerely
Ian.king
at Seattle
HI buddy,
How about u?I hav'nt received ur mail for a long time.Are u busy with ur
work?I will come back shanghai soon.We will do some detail talking after
being back.Thank u,Good Luck!
Ian.king
/////////////////////////////////////////////////////////////////////
//
恶魔吹着笛子来:
这个家伙竟然过了10几天才给我会信，下次到北京肯定斩他一刀:吃满汉全席,想到就
流口水。
梦魇:
///////////////////////////////////////////////////////
恶魔兄，你好！
前几封信都收到了。考虑到你人在美国，工作繁忙，就没有回信。现在既然呢快回到上海了，就不再客气了。 :-)
你上次给我带来.NET将加入GP能力的消息，着实令我非常高兴。我早就听别人隐约讲到过这种消息，但是从来没有得到确证。你带来的消息确实让我获得非常的确信。谢谢先！
关于GJ，这倒是我早就知道的。那个编译器我也下载过。不过看起来Sun一时还不会把这个特性正式加入到Java中。现在Java的发展还算健康，Sun不必要冒风险陡然增加语言的复杂度。这我是赞成的。
对于.NET，我抱着比较浓厚的兴趣和比较大的信心。虽然我认为MS在企业领域实在是落后的太远，但是好在.NET并没有完全定位在企业引用层面上，对于消费类和商业软件开发 也提供了非常好的支持。我知道你在这方面肯定有很多的新消息，希望你多给我介绍一些。
我已经开始相信.NET会成为下一代的主流商业软件开发平台，尽管基于传统的OS平台软件也仍然还会有很大的市场。不知道你对于.NET与COM之间的关系是怎么认识的？我就此向ATL开发组的Stefanovic请教，不过还没得到他的答复。
祝工作顺利！
孟岩
2001－11－12
/////////////////////////////////////////////////////////////////////
//
恶魔吹着笛子来:
这篇文章是，我对ms之行的一些观感。当作对COM做出了一个可能不是很公正的而且带有私人感情的结论。希望各位COM爱好者不要介意。
梦魇:
恶魔兄的这封信，我经常反复阅读。我觉得做任何评价都是画蛇添足，相信所有读者在读过这封信后，都会留下深刻印象。
///////////////////////////////////////////////////////
HI 梦魇:
你好，这么晚回信真是不好意思。刚从Santana回来，又忙着企划公司的二期融资的
Bizplan.昨天没有睡觉做完Bizplan ,今天又陪着美林银行的一帮人做完due dilligence.
下个礼拜但愿会空闲一些。
关于GJ我不知道你有没有仔细看了我的mail。说的好听一点GJ是挂羊头买狗肉。上次的
mail里面我贴了两段代码，第一段是我用GJ语法写的一个应用的Source Code 第二段代码是我用NMI把编译完毕以后Class文件Decode出来的代码。你可以看到虽然GJ在语法上实现了Template的语法但是他的实现却是把Template类修改以后用Object转型的方法来实现。你也应该知道GJ的Template是不允许类似int float这些基本类型作为Type parameter的。道理就在这里。GJ的实现其实是在走Java.util的老路。因此我对GJ是很失望的。VS.net的那帮人说C#的Gerneric功能是参考GJ的，如果是参考语法那还好，但是如果连实现的方法都采用的话那就不敢恭维.net的Template的功能了。另外他们还说今年5月份已经实现了Generic功能但是在市场推广的问题上争论到现在。因为要在C#加入Template功能那么CSL（.Net的字节码）也要加入template功能。.Net的特点是多种语言之间的交叉开发因此也就意味着其他的.net语言如VB也都要加入template。但是这对VB,pascal用户来说无疑有巨大的学习难度。应为毕竟他们是面向RAD的语言。
在.Net的问题上我和我的公司都是持保守态度的。这也是我们这次去Seatle的原因。这个问题我想和你提到的COM结合起来说比较好.要涉及企业应用没有一个强有力的BackBone是很难想象的。适应企业级的市场的最大原因不在.Net.而是在Iain McDonald和Brian Valentine 领导Windows2000项目部。Iain 和Brian这两个人是微软花重金从SGI和惠普买过来的。他们一个是SGI Cray部门的部门经理，一个是HPunix前任首席架构师，他们对Unix有丰富的经验。他们比他们的前任Nt4.0的项目经理 Jams.warton 在企业及的系统
上有更加丰富的经验。Jams.warton以前是搞VMS的。因此它也把VMS很多的弊病带到了NT比如内核系统虽然nt4.0宣称是微内核，但是实际上nt4.0的内核简直是一头猪。他几乎负责了nt所有的子系统的工作其他的子系统仅仅是内核系统某部分的功能扩展。还有比如内存管理竟然是采用FIFO这种最差劲的算法后来直到sp2的时候才替换为LRU。Iain McDonald和Brian Valentine是几乎把WINDOWSNT的依照Unix的传统从新设计。
.Net之所以出现是因为COM的混乱造成的。我认为COM是一个十分混乱的体系结构。主要的问题在于1.开发工具上的混乱2.同样的问题不同实现的混乱3.基本类型和内存管理的混乱。第一个问题和第二个问题是相关的。而且也是最主要的问题。COM的目标是一个各种语言都能使用的二进制标准。因此他最大的优点就是任何语言和工具都能支持和使用。但是目前各种语言和工具的实现都不一样，VB和VC不一样，就是VC还有MFC COM和ATL COM BastlCOM的区分，还有第三方的Delphi,BCB实现也不一样。各种不同的工具用不同的方法实现COM使得出现了同样的问题有不同的实现方法。各种方法之间性能参差不齐从而COM的初衷"跨语言编写"变成一句空话.例如用Delphi编写的COM通常会比VB编写的COM运行慢3-4倍。如果要用VB的写带有线程的COM他将会用进程来代替线程造成极大的资源浪费而VC的COM线程又采用传统的线程。COM的基本类型也是有问题的，COM的基本类型就是VARAINT这个巨大的Union。COM指望通过传送地址的方式来传送任何东西。但是这样一来就出现了内存管理的问题。一方面COM的对象采用refrence count这种愚蠢的方法来实现。很多情况下都要自己用手工释放资源。另外一方面很多基本类型的内存分配方式有好几种（还不包括不同工具和语言之间的问题）例如最基本的字符串处理，ATL中的BSTR你需要先Alloc用完以后Dealloc否则就出现内存泄漏，BSTR和char warchar之前的转型相当的麻烦稍有不慎就有泄漏的危险。如果用ms自己的bstr_t来做的话也有问题，如果采用bstr_t.copy()出来一个BSTR你不释放的话将会出现巨大的麻烦。另外有一些基本的操作例如实现一个Collection在ATL中将是一个很麻烦的事情，在VB中你用一个wizard就能完成，但是vb的collection无论在性能内存都有很多的问题。总之一句话用COM实现跨语言的编写就像是在走钢丝一着不慎满盘皆输。特别是采用第三方的COM库在最后集成调试的时候，一旦这些库中出现内存问题或者其他的问题你将不得不面对项目被从新设计或者推倒从来的危险。.Net的开发的目标就是用CSL公用语言来代替原来混乱不堪的COM架构。在类型，底层实现上面做到统一。从而降低跨语言开发的成本。.Net依然秉承COM的传统，但是对COM作了很大的改造。使得接口和开发方式上变的更为简单和方便。.Net上的COm越来越像Java的Class或者Beans。ATL在Beta2中仍然有所保留，但是已经不是作为主要的开发工具。对于.Net上的COM来说用C#来理解更加清楚一点。
但是我认为.Net的前景仍然模糊不清。首先.Net目前还有很多地方需要填补空白。从Beta1->Beta2将近有30%的地方作了很大的改变。因为在.Net上所有的语言都要依赖于CSL一旦CSL作了变更那么所有的语言都要做相应的变化这是对于开发商和程序员来说都是很可怕的事情。而且有些功能未必所有的语言都要用到例如template，过多的功能的混杂对程序员来说不是一个好事情第二性能问题，在Beta2中性能依然没有任何的改善。性能的关键在于VM的实现，但是就目前的技术来说vm的性能可能已经达到了极限。微软在这方面现在依然没有什么突破性的进展。这次我们去seattle，就是为了vm过去的。我们专门针对微软的vm作了一定的测试。我们和微软发放内部测试认证的几个厂商一起做了研讨会。结果会上的结果是一致认为需要在vm之外额外的加装编译器才能在对.Net性能作彻底的改变。但是微软至今还在犹豫。因为一旦加装额外的编译器将需要从新定位CSL的角色和意义。第三.Net的标准将是开放的，开放的标准将来就会出现兼容性的问题.第四.Net中另外一个很重要的角色XML目前情况也不是很好，首先Xml在电子商务上面并没有很出色的表现现在绝大多数的公司仍然在使用原有的EDI系统。再加上目前美国IT的大滑坡，Xml火爆的风光很难再看到。从技术角度来说基于Soap的协议应用适合于Long term的处理而对于short term的处理在性能上表现的很差。
好了就讲这么多，我昨天下了Boost库化了2个多钟头才编译成功。哎自由软件就是这样。Boost里面有一个写Python扩展库的类库还不错挺简单的。
Ian.King
/////////////////////////////////////////////////////////////////////
//
恶魔吹着笛子来:
梦魇的思维和文章总是那么深入让人无可挑剔，就连普通的email也是一样。这篇文章中让再次提到了python，我虽然研究了一段时间的python但是苦于没有人可以交流。Mengyan虽然相当感兴趣但是它很忙没有时间来做一些python的研究。如果Mengyan什么时候开始研究Python了我倒是希望能和他一起来开一个小网站推广一下中国的python。
梦魇：（to 恶魔兄）
那有一个小小的条件，这个网站必须同时关注我所谓的Modern C++ Style。我相信通过详尽严谨的编程风格和方法的指导，再加上Python这个最佳拍档，C++会焕发新的光彩，Python也会找到坚实的生长点。向所有读者推荐Bjarne Stroustrup的讲座录音。我反复聆听，始终觉得有新的收获。
/////////////////////////////////////////////////////
恶魔兄：
你好！非常精彩的一封信，我甚至希望能够拿去转载！你的时间这么紧张，还给我写这么长的信，我很感动。看了你的信，我很高兴。我对于微软内部的情况不是太了解，对于美国的舆论了解也不是很及时。你的信使我的很多疑惑得到释怀。
关于GJ的template, 其原理我早已知道。最初，我当然也是比较失望，但是后来想了想， template最大的优势就是其源代码的表现力。在这个角度上看，GJ的方法也还是值得称道的。 当然，效率方面就不能指望太多了。你说的C#加入Template之后给.NET带来的种种问题，也确 实是需要考虑的，从这个角度上说，我反而并不支持马上把template能力引入C#。
你对于COM的评论，我认为实在太精彩了！我曾经想学习COM，但是稍一涉猎就感 觉其中比较混乱（当然有些人会说这是“巧妙”），似乎有很多东西的复杂性完全是因为不断 地对前面的方案打补丁而带来的，不象标准C++那么清晰（虽然也很繁琐），其背后的理念也并不 完整和连续。我不是很害怕复杂的人，但是我很害怕混乱。所以我放弃了COM的学习。后来我 从一个从微软出来的工程师那里听说，COM的原始设计者对于其一些基本设计感到非常后悔，比如可以从任何一个接口获取其他任何接口的设计，但已经无法修改。微软如果不简化COM，在与Java的长期竞争中必然吃亏。所以.NET也可以看成是微软自救的方案。对于.NET，我的基本态度是欢迎。虽然有你说的种种问题，但是总的来说，微软能够跨出这一步，很了不起。当然，我觉得它跟Java一样，一开始把问题估计得太简单了，随着不断的进步，这个平台肯定会越来越复杂，这是不可避免的。Bjarne Stroustrup和Andy Koenig很早就对于Java做出过类似预测，现在基本得到证实。
我记得我翻译过的一篇文章，提到为什么C是一种伟大的语言，因为C背后的机器模型，就是冯.诺伊曼模型，非常简单，非常有 效，任何计算机都可以契合这个模型。C++的明智之处就在于，虽然Stroustrup给这种语言设计了一大堆特性，但是剥开其外衣，其背后的模型，也还是那个简单、小巧的C模型。这就保证了C/C++在解决问题方面极强的可适应性。而JVM和.NET背后的机器模型，应该说是很高级的，这 种高层次一方面在合适的应用上能够大大简化开发复杂度，提高效率，而另一方面在一定程度 上限定了其灵活性。这就是悖论。无法避免。我的观点是，让两者都存在，彼此尊重对方的存在价值。
你提到了.NET CSL的编译问题。类似的问题在Java上讨论的时间跟Java本身的寿命一样长。记得当年我刚刚开始接触Java时，在网上看到有位专家（忘了是谁）高呼：“任何事情也无法阻止Java编译化！”但是这么多年过去了，Java还是不能编译。而且先后几个性能神话(JIT, Hot Spot)都被一一打破。最近在网上有一个著名的大统计，把30几种主流的非主流的 语言放在一起，公平竞争，Java的总体表现惨不忍睹，甚至比不上一些老老实实的解释语言。看来确实是有一些困难。微软增加native编译器，实际上就意味着放弃.NET的一些基本设计理念。微软确实需要下很大的决心。而且，根据GCJ的实践来看，即使把Java编译成native代码，其运行效率与相应的C++甚至Perl相比，还是有很大的差距。.NET会怎么样呢？
C++的资源管理其实已经有了一整套解决方案。不过在某些关乎多线程的细节上还有瑕疵，需要进一步讨论。完全使用基于Reference Counting的Smart pointer对于系统效率的影响太大，所以STL和Boost才提供auto_ptr，scope_ptr等基于ownership的smart pointer。只有对于绝对必要的情况，才推荐使用shared_ptr。通过综合使用各种smart pointer，使用RAII原则和STL容器，在C++中做到绝对杜绝资源泄漏，会越来越容易。甚至最近Andrei Alexanderescu还提出了一些手段，处理更为复杂的资源同步问题，其实在C++中做到资源安全，已经是为期不远的事情了。剩下的问题主要是教育问题。比如有一些我们习以为常的做法，在modern C++中是应该禁止的。举两个例子，任何在类定义之外出现new []的情况都应该被严重关注，基本可以肯定是不应该出现的； 任何资源，如果找不到一个确定的owner，那么十有八九是设计失当。类似这些原则，一但结合标准库和boost库中的工具共同使用，再总结一些惯用模式，资源问题讲会得到妥善的 解决。我非 常想就此写一篇文章，可是一则自己的研究也还不够，二则时间不允许。
前不久在微软开发者之路的培训上，也听到微软工程师谈起XML/SOAP的性能实在太差，经过全力优化也无法突破一般协议的30％。看来新技术想要获得成功，确实是需要时间的。
非常高兴您能关注Boost库。它虽然也是一个Free库，但是其身份与普通的开源软件截然不同，其中的所有组件都将交付C++标准委员会讨论，通过后成为下一版C++的标准库组件。关于其中的Python组件，我很早就想告诉你，每次写信都忘记。其实这本身就说明一个重要问题，Python和 C++是一对非常合适的搭档，这一点不光在Python社区，而且在C++社区也获得了广泛的认可。为什么没有Perl库，没有Ada库，只有Python库。这本身就很说明问题。当然我也很怀疑这个组件能否通过标准委员会的苛察。但是Boost的身份决定它就是次标准，未来的任何一个编译器都一定会支持它。我曾经告诉过你，如果我只能学习两种语言，那就是Python和C++，其原因正在这里。
最近在www.technetcast.com上登出了Stroustrup在SD2001上的演讲录音，那里面 提到了他对于”正确使用C++”的一些看法，也提到了KCC＋MTL已经使C++在数学运算上超越了Fortran77 （你知道，这在计算机界被认为是mission, impossible）。总的来说，我感觉今天的C++，正在全力摆脱C给自己带来的沉重历史包袱，以一个年轻语言的姿态，迈向自己的明天。我还是充满信心 的。现在我最希望的是C++定义接口的二进制标准，采取一些切实措施减少项目文件组织的难度。我这里工程文件一多，经常发生symbol重定义的问题，确实很讨厌。
最近忙于Win32 API，大道理关心的不多了，谢谢你给我带来的消息。
孟岩
2001-11-19
<<未完待续，。。。。。最近我和myan正在讨论设计模式的问题希望过一段时间告一段落以后
我们能够再整理出来一点好文章以飨读者>>
