敢为你最宠爱的编程语言赌100000000美元吗？

我的命题是这样的：我需要开发一个应用程序，如果你能按时交付，那么我会支付给你一亿美元。并且此程序不涉及一些不可能解决的问题，当然各种困难和乱七八糟的问题那是一定的。

至于你想用什么编程语言来写，毫无限制，这一点我完全没有要求。关键是你得完成这个程序，并且使之能顺利工作。

任何一个大项目在开发过程中，需求说明总是会有所变化。我可以保证不会胡乱提一些会混淆你工作方向的要求。例如，你能添加一个拥有Photoshop所有功能的图像编辑器，甚至是增强版的吗？你能实现韩语和波兰语之间的自动转换吗？如果网络尚在加载中，界面上能不能出来一头可以操纵着到处转悠的3D立体模糊状的羊驼？这些要求我统统不会提。但是我可以预见以下这些情况的发生：

需要处理的数据比你预期的大5倍。

因为还需要在一些基于ARM的自定义硬件上运行，所以必须得是可移植的。

由于英特尔发布了20核心芯片，所以代码需要扩展到相应级别的处理能力水平。

以及还可以……接电话。

但是遗憾的是，我发现谷歌不想买我的博客了，所以我只能销掉这个一亿美元的报价。唉……真心无奈。

但是，假设这个报价是真的呢？你敢就此任务为你喜欢的编程语言赌上一亿美元吗？这将如何影响你对编程语言的判断标准呢？下面是我的观点：

类库的重要性远远超过核心编程语言的功能特征。

尽管Cayenne有许多相关的类型（很酷），但是它有创建Flash文件的功能和本地化外观的交互界面吗？D语言有富文本的转化类库吗？如何通过fpt从Mercury中获取文件？你真的想自己纯手工编写一个SVG解码器吗？

成熟和可靠的工具，甚至比类库更重要。

有没有人曾用Dolphin Smalltalk，或Chicken Scheme，或Wallaby Haskell等等试图解决过某个类似的问题？有没有人曾用某种编程语言试着解决此规模下的所有问题？你是否知道编译器碰到大型程序其速度不会成倍降低？分析器又能否处理这些大型程序？你知道怎么追查一个小小的变化是如何影响函数编写，从而导致内存出现离奇峰值的吗？有没有核心开发人员使用Windows版本工具，或者这工具被认为是二流平台？某个大型项目中的本地编译能否会严重影响大部分代码而导致全局性速度减慢（例如，90年代中期将Erlang转换为C语言就会发生这种情况）？

你的决定比你自己想象的更为依赖语言实施者。

一些基础类教科书上面的问题和实例教程，我们运行的时候总是特别美好。但是渐渐地，你会发现自己非常依赖于编译器，或者在系统运行时，会产生一些奇怪的情况，虽然这对于该编程语言创建的问题域毫无关系，但是会大大影响你下一个行为目标。

假设你有一个程序，可以操作一个大型的浮点值集合——浮点数量高达数以百计的兆字节。然而有一天，你的对象羊驼程序OCaml内存溢出，死掉了。当然你是很聪明的，知道大多数时间应该封装好程序中的浮点数量，等到需要的时候再取出来用。但是浮点数组却大多是不封装的，所以你用在了大型数据结构中。但是这样做内存依然不足。问题就在于“float”在羊驼程序中意味着“double”。C语言允许我们快速地从64位double类型切换为32位float类型，立马能节省成百上千兆空间。但是不幸的是，羊驼程序OCaml的实施者从未考虑过这件事，所以你不得不自己去使用编译器来做这个切换。ps，在这里我不是说在指责OCaml，此浮点类型问题在很多编程语言中都有。

与此类似，但同样难以解决的事情还有很多，例如，如果你发现在某一个数据集合中，垃圾收集器跨越了从“只有关注的时候才可见”到“几秒钟就能产生bug报告”的界限。话说，垃圾收集器已经经过了我们的精心优化，并且衍生多代，但是到现在最老的一代依然需要等待清理，等待它检查过上G字节的复杂结构并且做好备份之后，而与此同时，你就只能眼巴巴地等着。你能解决这个问题吗？当然纸上谈兵的那种就不要丢人现眼了。

这种有形的物质奖励法，然而，实实在在地影响了我的行为方式。因为有这么个一亿美元的胡萝卜挂在我的面前，我非常愿意独自去研究各种涉及实际的问题。纯粹的学术研究项目，其实是非常可笑的。我会用C语言写好应用程序的关键部分，这样一来，最后结果就又能回到我的掌控中，也就不至于之后突然发现语言系统设计者有关于标注、排列和垃圾收集器的选择有悖于我的最终目标。 Python和Erlang在大型的商业项目中广受欢迎，虽然它们也有各自不同的长处和短处，但是如果我需要支持一些非UNIX的嵌入式硬件，那么恐怕这两者都不足以胜任。

看到这里你有何感想呢？话说如果，假设，真的有这么多钱——一亿美元——让你改变完成任务的方法，转而用一种可靠又快速的标准方式，何乐而不为呢？

英文原文：Would You Bet $100,000,000 on Your Pet Programming Language? 翻译：codeceo

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。