完美的开发语言--现在只是梦想

今天看到CSDN上一条新闻，蔡学镛写的，我看了后感到很好笑，他的想法很可爱，可是很不现实。这条新闻在这里：

http://news.csdn.net/n/20080206/113451.html

我们逐个分析，为什么他所提出的这些观点都不现实：

1. 支持Unicode，以下几个问题造成没有什么开发语言能够完美支持Unicode 标准：
1. Unicode是一个标准，但是这个标准是不断变化的。以前Unicode可能只支持16位码（16bit），随着更多语种（人类交流的语言）加入这一标准，Unicode标准的变化是很快的。程序设计语言的发展可能跟不上这一标准的演化。
2. 很多公司或组织都会设计并发布开发语言，比如GNU G++和Visual C++，它们都在很大程度上支持C++语言标准，但是为了保证兼容性或是内部技术的局限，这些语言或多或少会和C++语言标准的一些细节冲突。同样，这些语言也会或多或少地不支持Unicode标准中一些细节。
3. 值得注意的是，地区，组织和公司在协助指定Unicode标准，经常会以自己利益为基础，影响这一标准的制定。同时这些地区，组织和公司在所控制的区域中影响开发语言的发展，影响开发语言对Unicode标准的支持。Unicode标准是否是一个国际性的标准，是否能够有一种语言能够完美地支持Unicode，这些都是一个悬疑。
2. 写一次，任何地方都可以执行，同样也是一个不现实的想法：
1. 现在已有Java，Adobe Flex语言在很大程度上已经达到这一目标。早期的C语言在一定程度上已经达到这一要求（基本上所有的OS都是用C写的，很多OS都使用Linux内核）。但是硬件的区别造成软件不兼容是无法避免的。
2. 这一想法无法实现的最大因素是，公司和组织的利益博弈。微软经常吹嘘.NET是跨平台，但是我们都知道所谓的跨平台是视窗平台，微软不可能帮助竞争对手Linux或Unix开发.NET。
3. Java最大限度地实现了写一次，任何地方都可以执行的目标，但我们也知道在视窗上运行的Java程序在Mac OSX上多少会有点问题。这是开发资源不够，无法将一个语言复杂到支持所有的系统平台。就算有组织能够达到这一要求，我觉得这样的语言肯定有很多问题。
3. 超小的执行环境，这个想法简直无法做到，当今的软件进行复杂的操作，需要使用很多内存（FireFox运行要75MB到200MB的内存，FireFox本身却没这么大），用于存储资源，暂时的变量，等等。
4. 包含GUI，这个想法有点怪，最基本的开发语言只要能够支持在一般的输出窗口输出字符串结果就可以，不需要GUI支持。这一点是多数语言开发者所支持的观点。所以GUI都是作为语言的开发包（SDK）形式，为开发语言提供便利。GUI程序设计有许多细节操作，所以很多开发包很大，这是不可避免的。在开发语言中直接支持GUI，甚至2D/3D开发包，会让语言本身变得很大，设计出的程序不可能很小（程序运行时占用资源会很多），这和#3是自相矛盾的。
5. 用更少，做更多，这也是无法实现的想法。没有什么语言能够直接达到这一要求，想要实现复杂的操作，就必须程序占用资源（内存，CPU）。比如FireFox，它很小，但是为了支持各种网页效果显示，它占用的资源就很多。我还没有见过什么浏览器只用20MB的内存来实现各种网页显示同时还支持其他杂七杂八的功能。程序语言也是这样，一个Java程序，看似简单，使用几个库类型就能进行复杂的操作，但是JVM在运行时，要同时引进这些类型，最后出现所占用的资源非常多。简单的代码可以进行复杂的操作，实现的代价是，简单代码背后的设计其实复杂无比，这些设计使用的资源就很多。所以用更少，做更多这个想法本身就是矛盾的。
6. 支援Meta-Programming，之所以有DSL的出现，是因为各个公司希望区分商业逻辑的设计和具体的开发技术。这样非技术人员可以使用DSL定义软件的商业逻辑，技术人员可以在一定程度上简单地将这些商业逻辑转换成相应代码，集成开发项目中。如果有无数公司，就有无数种DSL。如果要让开发语言直接支持任意一种DSL，只能从各种DSL的共通性支持，这样可能会局限各个公司在DSL设计的自由发挥。一点是很明确的，不可能有开发语言能够满足任何DSL设计需求，达到将任意一种DSL“简单”集成开发中的一部分。
7. 好用的剖析器，这个需求并入语言可能不难。但是不同的开发者对剖析器需求也不一样，所以兼容数种剖析器有一定难度，但不是做不到。这个想法是很现实的。
8. 能够呼叫C语言和嵌入汇编语言，这一需求在很多语言中实现，我赶到困惑的是回调和数据库有什么关系。C语言中的回调是面向对象程序设计出现前的消息回应机制，当今开发语言虽然也有回调机制，但是和C语言中的回调机制相差很大，我不知道在现代语言中支持C和C语言回调机制有什么重大意义。值得注意的是，现在对数据库进行操作的不同库（JDBC，ODBC，DAO，和Hibernate）所提供的功能，可能都超越了简单的使用C和C语言回调机制。我不太理解这个想法有何好处可言（我承认我不是硕士，所以学识肤浅）。
9. 丰富的资料型别Literal， 我觉得这个想法是比较现实的，很多开发语言都在向这一方面发展。这个想法是有好处和坏处，好处是变量定义更加简单，互通性更好，但是坏处是可读性会减弱。 的确，很多语言的升级是在向这一方面靠拢，但是也有趋势表明很多支持这一功能的脚本语言在远离这一功能，主要是可读性和程序运行结果的正确性方面的考虑。 比如Adobe的ActionScript，在编译时，编译器会非常仔细地检查数据类型的定义，泛型数据变量一般会造成编译器输出警告。
10. 轻量级的RPC/SOA，我不觉得这是一定要作为开发语言的一部分。并不是所有的开发项目需要RPC/SOA。我承认多数程序设计需要这一功能，才能制造出有商业价值的程序，但是很多简单的应用不需要RPC/SOA。据我所知，很多大型的程序系统，比如一个大型网站，并不是一个程序来执行所有任务，任务分成不同的服务程序来运行。程序间可以通过多种不同方式相互沟通，SOA/RPC是其中一种，也可以是其他方式如MSMQ，ISAPI，等等。简单地说一种完美语言只支持SOA/RPC并不能满足各种各样的需求，所以要完全集合SOA/RPC作为语言一部分，不如说是要集成各种已知的Remote Application Communation Protocol为开发语言的一部分。这样做，肯定会增加语言的复杂性。我觉得不现实。
11. 支援RIA，我觉得没有必要，就像GUI作为开发语言一部分一样，有点过度。RIA其实就是一种GUI，外加许多其他的Internet Application功能。它是一个复杂的开发技术，将其并为开发语言的一部分只会增加语言的复杂性。没有什么实质性的意义。
12. 有互动模式，这玩意有什么更高价值？直接用Console不就可以了？应该改为调试互动模式。增加语言在调试中的能力，说实话当今所有语言在调试方面都不好用，只要出了IDE的范围，调试都是很难进行的。调试工具的可用性是要提高的。
13. 免费与开放源码和组织坚强的社群，这和语言没有什么关系，一个是语言开发出版的模式，另一个是社区。

我阅读蔡先生的文章后，只是觉得，这些开发功能要是集合成一种语言，会把语言变得无比复杂，所生成的程序不能达到程序小，功能强的要求。这种语言，就现在的技术，是不可能出现的，也许再过几年等技术有了突飞猛进的发展，也许蔡先生的期望能够实现。

读 完这篇文章，我还有一个感觉是，蔡先生并不是希望有这么一个完美语言，他更希望一个简单的语言和许多开发包能够完美结合，这样他能够自如地设计任何他想实 现的软件功能。这其实和中国文化的平衡哲学有很大联系，任何事物都是不完美的，因为是人造的，开发语言和开发包也是一样。这里出现的重要概念不是完美的工 具为开发者实现完美程序，而是使用不完美的工具在万物制衡的概念指引下设计相对完美的程序。