64位普及引发完美风暴

IT界一直有一个悖论：到底是软件带动了硬件提升，还是软件吞噬了硬件性能。每一次硬件升级，你都会发现操作系统和软件还是在同样的时间内，完成了同样的事。

当AMD和Intel竞争到64位的时候，已经预示了一个新的时代，已经开始到来。64位CPU并不是一个新的事物，小型机上早就有了。但对于PC用户来讲，这次普及必然是革命性的。对于那些依赖于PC操作系统的软件开发商们，这也将是一个不小的革命。

在所有革命都在悄然进行的时候，软件工程也在酝酿着新一轮的发展。

从Brooks那个精彩的《没有银弹》论断诞生之日开始，无数精英们都在使用自己的方式来提高软件开发效率。很多系统提出的时候，都是高呼着“高效的生产率”上台的。

其中，呼声最高的是.NET。号称软件开发效率能提升10倍。在.NET发布会上，微软使用了很多案例来证明这点。.NET提供了非常好的开发框架，这点对于以前进行Web开发来讲，是一个大大的革命。另外.NET还在此基础上，提供了丰富的类库支持。更加提升了开发效率。

谈到.NET，就不能不谈Java。Java和.NET一样，也是运行在一个虚拟机上。不同的是，Java不提供本地化过程。在Java所提倡的开发效率是：“一次编写，到处运行”。但是，在很长的一段时间中，很多人认为Java的运行效率跟不上。因此不适合开发桌面应用。这在很大程度上限制了Java的普及。但是在一些高性能的服务器上，Java的优势却发挥的淋漓尽致。开发商充分利用J2EE等优秀成熟架构，来部署稳定、高效的应用服务器。现在电信几乎都是使用J2EE架构。

另一个呼声很高的是动态语言。现在最火的是Python和Ruby语言。

我们知道，编程语言的发展是从最基本的二进制CPU语言开始，发展到汇编语言，进而发展了高级程序语言，这些一般是说C、BASIC、Pascal等。随着软件工程的规模扩大，慢慢发展起来的软件工程方法，开始影响着语言。这里面最大的就是面向对象概念的提出，导致了大量的支持对象概念的语言出现。最有名的就是C++,Delphi,C#,JAVA。每一次语言的发展，都在降低着代码效率。可是每一次新的语言都坚决地前进着。这就是生产率的力量。

以非常有名的“鸭子理论”（看上去是鸭子，走起来象鸭子，那就是鸭子）提出来的动态语言。也是高呼“生产率”，吸引了很多开发者。可是，它也是遭遇了运行效率的问题。引来很多争议。

历史总是有惊人的相像，每一次软件方法的发展，都伴随着性能争议，每次都带动了硬件的发展。而硬件的发展，又为软件方法的的发展铺平了拦路石。不管谁是鸡，谁是蛋。重要的是，这是进化的鸡，进化的蛋。进步才是最重要的。

当我们在谈论硬件性能被软件吞噬的时候，软件工程已经发展到了空前的高度。我们现在已经不可以想象，如何使用汇编，编写一个简单的应用系统。现在的复杂度，已经迫使我们使用更高层次的抽象，对系统进行高层次的架构。可是每一次抽象，都意味着不同程度的运行性能降低。汇编抽象出指令是这样，C抽象出语言是这样，C++抽象出对象是这样，Java抽象出虚拟机是这样，Ruby抽象出类型也是这样。.NET抽象的时候，针对这个性能问题，又提出了一个本地化（在本地进行编译）的概念。这是一个好的想法，可是对于抽象本身并没有帮助。

每次好的思想都能将运行性能的拦路虎打败。这些除了依赖于硬件性能的提升，更是基于人们解决问题过程中对于新思想的依赖性。

我们在抱怨软件吞噬硬件性能的时候，其实正是我们遇到新问题的时候。硬件的发展总是有它发展的需求所在。在这个时候，我们不是抱怨，而是要正视这个发展趋势。

软件开发商对于开发效率的追求远远高于运行效率。因为开发效率就是开发成本。但是客户的体验又是软件开发商必须考虑的方面。如果客户不满意，那么再好的办法也值得商酌。在这两者之间来回权衡，是一件痛苦的事。因此往往是好的方法能带来高的生产率，但是却暂时不能使用。

可是，如果，这些运行效率不再是问题的时候，会怎么样呢？

64位编程，对于应用软件开发本身来说，并没有多大的变化。这得归功于微软的不懈努力，以及各大硬件厂商在兼容性上的考虑。CPU的X86架构当年从16位转换到32位的时候，就非常明智地选择了一条兼容16位处理器、逐步推广32位处理器的发展路线。与当时架构虽然好，但是却不兼容16位的RISC架构来比，兼容最终笑到最后。RISC最终也只能被被市场淘汰，在一些细小局部应用。

这次从32位到64位的转换，也是遵循着兼容的原则。所以大部分32位上的应用软件都是可以顺利运行。除非调用了依赖于32位的硬件驱动。

表面上，64位编程和以前不存在什么差异。这也正是容易误导我们的地方。技巧的表象，容易让我们忽略技巧背后的方法变革。在运行效率不再是问题的前提下，一些人会慢慢尝试使用具有更高开发效率的思想和方法，而不再拘泥于原有的方式方法。

在.NET刚发布的时候，大家的普遍想法，都是.NET适合进行Web开发。而原来的Win32平台上的应用开发，不如使用原生的语言（如C++/Delphi）进行开发。Borland公司也正是看准了这点，推出适合原生Win32开发和.NET开发的Delphi2006，两种方式同时提供。

可是，这种方式并没有被大家接受。大多数开发.NET还是选用了Visual Studio.NET，而原本在Win32下开发的，还是用Delphi。这说明这两类选择正在分化。随着CPU速度的提升，性能不再是那些选择Win32原生平台开发所需考虑的问题的时候，选择.NET几乎是必然的。这样开发成本会降低很多。最大的成本就是不需要招聘两类语言的开发人员。这对软件开发商是一个非常大的诱惑。

看问题，总是要看趋势的。现在正在方法界流行的动态语言，也有类似.NET的特点。可以预计其发展趋势必然随着硬件性能的提升，而蓬勃发展。

很多Python和Ruby的追随者，都是奔着“高效”去的，不是运行效率，而是开发效率。除了前面讲到的鸭子理论。动态语言中针对元数据MetaData的编程能力也是非常强的。简单点说，就是让代码编写代码。减少程序员的人为因素本身就是提高开发效率。

增加复用是提高效率的本质所在。最基本的是这些动态语言提供了丰富的类库，对于业务逻辑的最大程度的复用，也是动态语言提供的方式之一。这点Java语言也学习过来了。利用IoC实现的Spring框架就是利用这些特性来做的。Java在提高开发效率方面，很是不遗余力，很多动态语言方面的特性，都在后续版本中加进来了。

这几年炒的MDA的概念，在某种程度上也是因为没有令人满意的实现，在推广上没有大面积推开。在这方面，Borland公司提出的ECO概念比较先进。相信随着PC机器性能的提升，在应用软件的开发领域，必将能够好好利用起这个技术。

其实，很多概念并不是新鲜的，也不是没有成熟应用。只是很多技术都需要高性能的服务器做支撑。所以在一般的应用软件领域很难被广泛使用。因此，随着以前只有小型机才有的64位CPU安装到普通的PC机上，很多原本只能在小型机上的技术都可以移植过来。这个正如军事领域的技术应用到民用领域一样。飞机原本都是军事领域发展高端技术，后来应用到了民用航班，带给我们的变化是巨大的。PC的发展更是这样。

很多技术都和64位本身无关，可是这些技术又都是依赖于高性能的CPU才能茁壮成长。如果只是看到64位技术本身，对于应用软件领域的开发来说，确实没有多大影响。很多方式方法会借着这些营养，努力成长自己。这又得提到开篇的那句话，到底是谁促进了谁。硬件的性能提升让软件方法也可以发生变革。新的方法又使硬件的性能优势不能体现，促使了新的硬件技术发展。如果我们现在还在使用DOS，还在使用Windows95，你根本不需要购买现在市面上的任何档次的硬件。任何一个可以找到的配置应对这些应用都是绰绰有余。

不管怎么样，正如前面说的，不管谁是鸡，谁是蛋，关键在于两方面都进化了，而正是这些进化，保证了我们能够适应新时代、新需求下的应用软件开发。64位的普及，引发的不是技巧性的变革，而是开发方法的变革、开发效率的提升！