Gilad 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/ 效率的争论,还是非常有趣的。
查看英文原文:"Original Sin" (Would Java be Better Off Without Primitives?)
评论