RW:C++和internet时代相关吗？
BS:当然，C++代码不适合于下载到一个不安全的计算机中；
不过大多数计算机都不是这样的。
C++是关于系统编程和有一些资源约束和（或）一些严重的
性能需求的最好的语言。Google是一个例子。操作小应用
(gadgets)的嵌入式系统是另一个例子。
并且，有许多程序并不直接和internet交互。对于这些程序
世界并没有什么太大的变化。
RW:对于.net平台带来的语言无关性(language independent),
你认为对C++的影响是什么?
BS:有许多和C++相关的团体。一些程序员工作并紧密捆绑在
一个执行环境中(如.net,一个特定的嵌入式系统，或者一个
特定的UNIX的变体上)。对于这些人来说，他们最关心的是
平滑的和他们的平台集成。
对微软.net世界中的c++的重视已经足够多了，因此C++仍然
会作为一个主要的语言；不过，许多强调的重点将会不可避
免的放在对平台的集成和对其它语言写的代码的互操作。在
很长的一段时间内，人们将会损失一些严重的平台依赖性来
得到一定程度上的语言无关性。这将会阻止c++的更加新的
部分的实验，不过如此多的c++程序员使用被愚蠢的限制的
子集，在短期.net可以确实的刺激更好的c++使用。
就是说，我的心和那些为平台无关性和移植性(portability)
而战的程序员同在。作为那些程序员，瘦(thin)接口和平台
无关性库将被作为重点。ISO标准把C++子社团捆绑在一起，
并阻止c++语言变成乱七八糟的各自为政的方言。
RW:ISO/ANSI C++标准委员会开始讨论对C++语言和库的改变
和扩展。你最希望看到的扩展是什么，或者，你最强烈反对
的是哪一个？
BS:我最通用的观点很简单:我们应该谨慎对待语言扩展，
强烈要求扩展标准库。我的理由也几乎同样简单:我们需要
提高移植性和稳定性，这不能从一个变化的语言中得到。
库则不一样。如果我们得到一个"dud"库，用户能得到一个
更好的替代品来忽略它，或者简单的构建(build)或买一个
比从他们的编译器提供商那得到的更好的实现(implement-
ation)。
人们最近对编程语言的期望越来越多，不谈导致这种结果的
各自为政的语言,那些需求能够很容易的和最安全的通过提高
标准库的大小来达到；特别是我们象在I/O流和STL库中做的
那样把标准库作为框架(framework)扩展来组织。
一个语言的成功的扩展需要指导(direction)，和标准库的核
心的成功指导一样。在语言届，我喜欢重视使语言更统一和更易
学的小工具(facilities)。因此程序员怎么除了语言细节外
让他们的工作能够完成呢？最主要的影响将来自标准库提供的
新的东东。一个更大的标准库不仅节约工作量，也教人技巧
和风格。一个早期的c++的问题是虽然提供了对OO编程的很好的
支持，但c++并没有提供一个很好的库来向用户演示OO。这导致
了很多困惑和神话。泛型(generic)编程的介绍做得更好，最
主要的是STL提供了一个具体的例子来使用和学习。我只希望
我有同样的好的和有用的关于异常(exception)的使用的例子。
我正在做一个叫XTI(eXtended Type Information)的库，提供
一个对通用c++类型信息在反省(introspection)和程序转换
(transformation)中使用的接口。我希望在标准库中看到象这
样的东东。总的来说，我希望看到更好的对分布式编程的支持，
并相信那应该是主要的库应该加的。
RW:你看见的C++编程中的最重要的潮流是什么?
BS:C++世界太大了，很难知道你所看到的东东
是不是潮流。我想有一个在嵌入式团体中的对
C++使用的巨大的增长，不过我并不确定。我
知道有一个对"template metaprogramming",
"generic programming"和"generative pro-
gramming"的兴趣的增长，不过我不能肯定
它有多广的基础。我猜想这些是在先驱和学者
中的热点话题，不过不是全部，新技术将会在
未来几年进入主流。现在有越来越多的C++开放
源码项目，不过我也不肯定。C++世界太大，
一个人很难完全懂得它。
新技术象泛型编程和新的语言工具如模板异常
用很慢的速度进入开放源码社区，用我的胃口
来看当然是太慢了。我希望看到开放源码项目
接受更多的现代编程风格。这个保守的情况
是因为开放源码团体不能只是“用一个课程来
发送他们的贡献“来保证所有人都有相同的和新
的对工具和技术的观点。
RW:C++是否已经达到当程序员需要一个C++的设计
标准时会自动转向C++呢?
BS:不，世界没那么简单。程序员，象所有人一样，
受职业市场的影响。程序员，象所有人一样，喜欢
高估新东东优点(被过分炒作的)，低估真正的缺点
(几乎不被提到)，并且确信他们不会转行后失去
什么。注意有时候C++是一种“新语言”，人们
转到它上面时的理由和它的技术强项和弱点无关。
在理想的世界中，人们客观的按他们的需求选择。
在真实的世界中，我们很主观，而且很少真正知道
我们将来的需求。有些情况下，我们会失望的。
RW:不象Java,c#和VB,没有人拥有C++。在这种情况下
，C++更象Linux和其它开放源码运动的成员。不过
它好象没有享受和开放源码运动一样的紧急需求。
为什么呢？
BS:C++是实际的，革命性的语言，并且C++是没有政见
的，除非你想把“无方言，被ISO标准委员会控制“
作为政见。并且，不同意见的支持者不公平的把
C++描绘成M$的语言。另一个问题可能是我更注重
性能和尺寸，对新手和学生有很小的吸引力。然后，
我不喜欢的炒作是有效的进入市场的方法。
RW:你对“方言“库的提供者的前景怎么看？
BS:作为Addison-Wesley的"C++ In Depth"系列的编辑，
我试着挑选有趣和重要的话题，当然还有好作者。
我喜欢把库作为使想法和技巧变得实际的方法；
这就是为什么你能在ACE，Loki和BGL发现好书。
每个这些示例想法更少为众人所知，并且不象我所
期望的那样广泛使用。然而，这不意味着我认为
所有这个系列中所介绍的库是完美的。我一直希望
有更好的库。特别，出版一本ACE书不意味着，我
更喜欢开放源码库，而不是商业库。它们都扮演重要的
角色。
我不是商人，所以我不宣称我知道商机在哪，并且
我也不是经济学家。然而，我的感觉是利润不是
几乎是下定义，成功的“方言”库和工具是那些有
利润的。
实在(solid)的工程,质量，尺寸，互操作性，教育性，
可维护性和技术支持是无报酬程序员所无法竞争的。
注意当免费和开放源码提供者成功完成一个大型系统，
他们与为利润的主题相比会出现这个问题。程序员
有时需要解决吃饭问题。
我注意到c++标准库的商业实现这几年很流行，因此
我不把标准库作为必要的和商业库的竞争。我希望
c++标准库能作为更特化的库的好的基础，很多这些
特化库可以作为“方言”。
RW:C铺平了C++的路。你看到C++为下一种语言铺平了道
路吗？哪一种paradigm变化(例如:过程 vs. OO)应该
开发者希望作为结局?
BS:我假设世界被单个下一个语言过分的打断了。特别，
Java和c#都不符合这种情况。
并且，有太多关于"paradigm 变化"的讨论。OO编程并不
比面向过程编程在每个方面都优秀。我考虑"技巧"和
“风格”比"paradigm"更多。C++支持多种风格，
它是multi-paradigm语言。这很重要，因为被
炒作为的"paradigms"看上去不可兼得。相反，
风格是可以兼得的。
因此，我不猜想"下一个paradigm",而是预测是否和
何时它会到来，它会让过程，OO,GP技巧良好的共存。
RW:模板的设计目标是不是能在编译时的计算的能力，
或者只是个令人欣喜的巧合？
BS:两种情况都有一点，我努力工作使基本要素正确，
如允许内联(inlining)和调用和定义上下文的融合
(merging)。我的重点是一些重要例子的灵活和效率，
如对一个数组的求和。加上一个对通用的自然的喜好，
而不喜欢特别目的的特征，和不喜欢不必要的我所没
有梦想到的技巧(如STL)的限制。模板重整了C++的
剩余部分。我不会喜欢去做一个只能做我只能想象
的东东的工具。
RW:模板怎样能做得让开发者更易于学习呢？
BS:我觉得没有理由相信模板比类和类结构
更难学。当我介绍这些时，关于这些特性如
何复杂，不安全，无法管理和无用的抱怨
震耳欲聋。
令人沮丧，许多程序员从新的结构退了回去。
我想部分原因是当对待重要工具时的自然的
小心。然而，另外部分原因是想法上的懒惰，
惧怕新东东会打破舒适的旧方式，还有就是
许多软件企业排斥视作竞争的东东。
如果是这个原因的话，我们只能等待当更多
的人学习良好的使用新技术后，当新鲜感
逐渐消失后，当我们的工具更加改进后，
抱怨声消失了。模板允许比它的替代者
对一些重要的解决方案和技术的更简单的
表达，并且能提供更有效率的代码。在更
长的时间里面，简洁表达的快速的代码
通常能获胜。
