@trevorburnhamDouglas Crockford 认为 JavaScript 有好的方面，并开发了 JSLint 工具来保证开发者远离 JavaScript 中的糟粕。JSLint 允许的语法子集值得拥有自己的名字，我们不妨称之为 GoodScript.
[...] CoffeeScript 不是将 JS 变成 Ruby 或 Python, 而是通过一套语法，来更好地发挥 JavaScript 内在的优秀。
ECMAScript 5 则引入了
"use strict" 指令来限制 with 等语法的使用。CoffeeScript, GoodScript, ECMAScript 5 的目标是一致的：远离糟粕，同时提供有用的、安全的语言特性给你。
GoodScript 没有提供新特性，ECMAScript 5 的严格模式，大部分浏览器还不支持。然而，我们不想等待。
剩下的选择是 CoffeeScript. 好处：
- 特别适合 web 开发。这可能是其他 JavaScript 编译器没做或做得不好的地方。
- CoffeeScript 对 JavaScript 的封装适度。这样能使得编译后的代码比较容易阅读，调试也就不那么困难了。
CoffeeScript 的编译器提供客户端版本。这样，使用者可以自由选择，开发者也可以快速开发新功能，而不受标准的局限。由社区的愿景和需求推动 CoffeeScript 的发展，这很不错。
发明自己的语言
你可以去做，这会是一个很好的练习。作为 JavaScript 编译器的开发者，将拥有无上荣耀。发明自己的语言，危险之处在于：你认为最终你将比 JavaScript 做得更好。语言设计很难，我敢打赌你的语言很难扩大市场份额。CoffeeScript 尚未进入青春期，就已经有抱怨的声音了。
你可能会为自己的编译器能编译出简单、可读的代码而骄傲。可是，一碰到特殊情况，你就会郁闷得想撞墙。
你的语言里将会出现惯用法。接着，你马上会发现有人会破坏这些惯用法（除非你的语言刚好支持宏）。
风凉话就不多说了。立刻去开发自己的语言吧，你会成为一个很好的程序员。
作为编译目标语言，JavaScript 缺少什么？
作为编译目标语言，JavaScript 重获新生。在 JSConf.US talk 中，Brendan Eich 表示：Harmony 规范的目的是让 JavaScript 成为更好的编译目标。编译后的 JavaScript 有可能比手写的 JavaScript 运行效率更低，这就和编译后的 C 有可能比手写的汇编语言效率更低一样。幸运的是，JavaScript 的瓶颈主要在 DOM 操作上，语言本身的效率损耗相对可以接受。虽然话是这么说，但一些高效的源码语言编译后，由于 JavaScript 本身的问题，可能极其低效，以致于无法在真实环境中使用。Harmony 规范中已经有部分特性能保证避免这类问题。
合理的尾部调用
function isEven(number) {if (number === 0) {
return true;
}
else {
return isOdd(number - 1);
}
}
function isOdd(number) {
if (number === 0) {
return false;
}
else {
return isEven(number - 1);
}
}
isEven(100000); // InternalError: too much recursion
上面的代码，在目前的浏览器中运行，会堆栈溢出。
可以通过蹦床(trampolines) 技巧来优化：
function bounce(ret) {
while (typeof ret === 'function') {
ret = ret();
}
return ret;
}
function isEven(number) {
if (number === 0) {
return true;
}
else {
return function() {
return isOdd(number - 1);
};
}
}
function isOdd(number) {
if (number === 0) {
return false;
}
else {
return function() {
return isEven(number - 1);
};
}
}
bounce(function() {return isEven(100000);}); // true
通过 bounce 方式，在运行
isOdd(99999) 时，isEven(100000) 已经完成并从堆栈中退出了，因此不会造成溢出。幸运地是，ECMAScript Harmony 已经考虑到了这一点，会自动进行优化。这对程序开发者和编译器开发者都是有益的。
Lambdas
lambda 并不神奇。简言之，lambda 就是可调用的东西，比如 function, 但需要遵守 TCP（Tennent 一致性原则，Tennent’s Correspondence Principle）。TCP 要求：用一个紧邻的 lambda 对表达式或代码块进行封装，不会改变被封装的代码的含义。很显然，JavaScript 的 function 不是 lambda:
function _disibledevent=>return 1;
}
one(); // 1
封装后，返回值发生了变化：
function _disibledevent=>function() {
return 1;
}());
}
对于接受两个参数并将其求和的代码块，lambda 语法提议写成：
{|a, b| a + b}对于上面的例子，采用 lambda 封装将保证返回值和封装前一样：
function _disibledevent=>||
return 1;
}());
}
one(); // 1
lambda 块的稻草人提案目前还没有提升到 Harmony 规范中，让我们一起努力吧。
浏览器缺少什么？
JavaScript 的兴衰存亡离不开浏览器。JavaScript 的新生，也需要浏览器的靠谱支持。Mozilla 发起了一个 SourceMap 项目，这可以使得在调试编译后的代码时，能映射回源码的对应代码行。这太 cool 了，能极大的减少调试成本。
听说 Webkit 的小伙子们也在干同样的事情，可惜我找不到任何证据了-.-
通晓数种语言
JavaScript 在浏览器上的垄断，意味着前端程序员都会同一门语言。然而，编译器的差异性，会使得 CoffeeScript 程序员，很难立刻看懂基于 Traceur 的 JavaScript 代码。这种分歧不可避免。比如有 C, 同时有 C++ 和 Objective-C 等各种语言。Java 也一样，基于 JVM 还可以选择 Clojure 或 JRuby. 微软意识到这一点，开发了 CLR. C#, Basic, IronPython 等都可以运行在 CLR 上。
前端中的沟通障碍并非新鲜事物。一个 Dojo 程序员，难以立刻明白基于 jQuery 或 YUI 的代码。
拥有多种源码书写语言会增加社区的沟通障碍。程序员仍需要了解 JavaScript. 至少一段时间内程序员还需要懂得 JavaScript. 但在短短几年后，他们可能会更了解其他源码语言。
总结
能有机会目睹 JavaScript 的新生，是件很棒的事情。在 JavaScript 编译的竞争中，很难说谁会最终赢得市场份额，但毫无疑问，这肯定会很有趣。如今，CoffeeScript 蓄势待发，但我相信许多其他成功的源码语言将接踵而至。你的想法呢？
标签： JavaScript
相关文章：
Javascript诞生记
Javascript继承机制的设计思想
JavaScript，只有你想不到
JavaScript重构之JavaScript的测试
理解JSON：3分钟课程
最新评论