新文章移至
http://cffile.sinaapp.com/?p=24Gilad Bracha重新挑起了一场有关编程语言设计的争论，特别是一门编程
语言可以兼顾面向对象思想和原生数据类型吗？他在博客中写道：“我经常说，Java的原罪在于它不是一个纯面向对象的语言（一切皆对象的语言）。”
文中讨论的主要内容不是纯面向对象语言的优点，而是提出了一个问题：
Java如果没有原生数据类型，是否能保持高性能？答案是肯定的。
Gilad首先拿类型变化举了一个简单例子。Java语言的char类型最初用16位
二进制表示（符合当时的Unicode标准）。但是当标准改变之后，“人们用Java
处理unicode时不得不自己处理编码格式”。至于性能的问题，他提供了几个例
子演示如何在不影响效率的情况下处理对象。
那么我们如何避免使用原生数据类型而又不损失性能呢？
Java有一套强制静态类型机制，它被编译成静态类型的汇编语言
（Java字节码，即JVML）。它支持静态类。我不建议使用这些特性，但是
我们需要知道。我们唯一需要做的就是根除原生数据类型。
假设我们存在一个静态类Int表示32位整数。编译器能够把该静态类转换
为int类型。因此，我们就可以编写标准的Java代码而无需损失任何性能。
更有趣的例子包括：以操作符命名的方法、==操作符、实例锁定和数组协变等等。
结论：
总之，Java原本可以完全面向对象而不受明显的性能影响。但是它过去不是
，现在不是，可能未来也不是。光荣易逝啊（Sic Transit Gloria Mundi）。
文章的读者回复大多数都同意Gilad的观点。
摘选如下：
* Daniel Speiwak——事实上，听起来很像Scala。Odersky和朋友们提出
了一种有关协变数组和消除原生的解决办法：泛型特化。
* abies ——可能并非如此简单。尽管我也认为将原生类型编码为对象
可以非常高效，但是总会有损失的。Smalltalk就是一个例子——大多数
实现都把小/大整数区别对待，小整数被存放在非环形指针里。这意味着
整数在不同大小转换时表现出巨大的性能差异——对每一个整数的处理都
有一些影响。我非常高兴Java在数学运算法方面有可能和C++/Fortran一样快。
* Osvaldo Doederlein——有关面向对象vs原生数据类型的讨论首先面临一个
挑战：举出至少一个纯面向对象语言相比拥有原生数据类型和数组的语言
没有显著的性能损失。不要拿高层次的应用基准来糊弄我。我要的是数学
运算/数组的微基准，或者是现实世界低层次的运算，如数据压缩、视频编码、
网络栈等等。
讨论也包括一些技术上的例子以说明两者之间的鸿沟。
也许有关“OO争论”最有趣的一些方面在这次讨论中并没有提到。比如：
* 效率vs面向对象纯度是80年代和90年初期（Java诞生之前）Smalltalk
和C++语言之争的焦点，其实这是一个完全不相关的辩论，因为它忽视了
OO语言诞生的原因。当时最纯正的OO语言是 Smalltalk和Self，两者都明确的
以Simula（不是Simula I）为榜样以建立一种支持领域专家简单直接的表达问题
和解决方案的语言。影响性能是完全可以理解的！
* 文章作者认为 Smalltalk在嵌入式、毫秒时间计时、切换的程序和实时的
图形显示系统（应用于喷气式飞机）中优于C++应用。这是因为Smalltalk
应用了很多编程技巧（比如预编译的方法和Smalltalk对象可以直接与
硬件打交道而不依赖操作系统）以获得性能优势。关键在于，编写相同
的C++程序所花费的开发时间缩短了1/3。
* Java从来没有真正想成为一个面向对象语言。如果Sun在获取Smalltalk
授权时没有受到阻碍（ParcPlace的纯粹商业错误），Java可能根本不会存在。
Oak将继续沿着“智能烤面包机”的道路进化，而不会成为Java的基础。
Java的目的就是融合Samlltalk和C++的各自最佳特性，而不是成为一种纯OO语言。
* 从代码和语言“特征”的角度谈论OO纯度是绝对错误的。对象是一种隐喻工具，
开发人员可以借此更好的理解问题域，并获得完全不同的、更加简单和富有效率
的设计和架构。如果一门语言是纯面向对象，“一切皆对象”，仅仅意味着你
可以直接表达你的设计而无需考虑这些这些设计在机器层面如何实现和执行。
如果基于为何编程语言这样设计、在机器执行效率不是关键因素时对象是否
真的提供了一种建立设计的好办法等问题来看待纯OO/效率的争论，还是非常有趣的。