Ruby 和 Javascript 之间的主要语义差异是什么
如果要在 Javascript 引擎之上（在浏览器中或在独立的 V8 或 Spidermonkey 之上）实现 Ruby，那么 Ruby 和 JS 对象模型之间的关键阻抗不匹配是什么？
If one were to implement Ruby on top of a Javascript engine (either in the browser or on top of standalone V8 or Spidermonkey), what would be the key impedance mismatches between the Ruby and JS object models ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最引人注目的显然是 ECMAScript 是基于原型的，而 Ruby 是基于类加混合的。另外，在 Ruby 中，封装是通过对象完成的，在 ECMAScript 中是通过闭包完成的。
然而，我的猜测是，Ruby 的控制流构造将是比其对象模型更大的障碍。毕竟，James Coglan 的 JS.Class 基本上是 ECMAScript 中 Ruby 对象模型的实现，但事实并非如此大的。
ECMAScript 只是缺少在其之上构建您自己的控制流结构所需的工具。通常，您需要 GOTO、延续或适当的尾部调用。如果您拥有其中之一，您就可以轻松实现其他所有内容：异常、循环、开关、线程、Fiber、生成器、协程……凡是您能想到的。
但 ECMAScript 没有它们（并且有充分的理由，至少在 GOTO 的情况下）。 ECMAScript 唯一具有足够强大的控制流构造，能够在异常之上构建其他构造。不幸的是，这些速度相当慢。 （尽管如此，它们已被用作实现基础，例如在 Microsoft Live Labs Volta 编译器中，它使用 ECMAScript 异常来实现 .NET 异常、迭代器、生成器甚至线程。）
所以，基本上如果不是整个解释器（如 HotRuby 的情况）、执行全局 CPS 转换或类似的事情，那么您至少要实现自己的调用堆栈。
基本上，您想要从运行在 ECMAScript 之上的 Ruby 引擎得到的是
抛出/catch、异常等）、不幸的是，当您不得不诉诸诸如管理自己的堆栈、进行 CPS 转换、在异常之上构建等技巧时……事实证明，您只能选择三个目标中的两个。
The most in-your-face one is obviously the fact that ECMAScript is prototype-based and Ruby is class-plus-mixin-based. Also, in Ruby, encapsulation is done with objects, in ECMAScript with closures.
However, my guess is that Ruby's control flow constructs are going to be a much bigger hurdle than its object model. After all, James Coglan's JS.Class is basically an implementation of Ruby's object model in ECMAScript and it's not that big.
ECMAScript simply lacks the tools needed to build your own control-flow constructs on top of it. Typically, you need either
GOTO, continuations or proper tail calls. If you have one of those, you can easily implement everything else: exceptions, loops, switches, threads,Fibers, generators, coroutines, … you name it.But ECMAScript doesn't have them (and for good reason, at least in the case of
GOTO). The only control-flow construct ECMAScript has that is powerful enough to be able to build other constructs on top of is exceptions. Unfortunately, those are pretty slow. (Nonetheless, they have been used as an implementation substrate, for example in the Microsoft Live Labs Volta compiler, which used ECMAScript exceptions to implement .NET exceptions, iterators, generators and even threads.)So, basically you are stuck with implementing at least your own call stack if not an entire interpreter (as is the case with HotRuby), performing global CPS transforms or something like that.
Basically, what you want from a Ruby engine running on top of ECMAScript, is
throw/catch, exceptions etc.),Unfortunately, when you have to resort to tricks like managing your own stack, doing CPS transforms, building on top of exceptions, … it turns out that you can only pick two of the three goals.
JavaScript 是图灵完备的，所以理论上你可以实现任何东西，包括其他编程语言。 实现 (JavaScript) 和目标语言 (Ruby) 有多么不同并不重要。 Ruby 和 C 等语言之间的阻抗不匹配是巨大的，Ruby、Python、Perl 和 JavaScript 本身都是用 C 实现的。
在 JavaScript 中实现 Ruby 应该比在 JavaScript 中实现 Ruby 容易几个数量级所以用较低级的语言。对你来说，你有很多 Ruby 的优势，而且 Ruby 的标准库都是用 Ruby 本身编写的，所以一旦你有了一个基本的解释器，事情就会逐渐走下坡路。
在 JavaScript 中实现高效 Ruby 解释器可能更困难，但仍然是可能的。您最终可能会将 Ruby 翻译为 JavaScript，以便优秀的优化器可以发挥作用。
因此，不要考虑 Ruby 和 JavaScript 之间的差异。查看 Ruby 的标准实现，并考虑如何在 JavaScript 中实现那个。
JavaScript is Turing-complete, so theoretically you can implement anything, including other programming languages in it. It doesn't matter how different the implementation (JavaScript) and the target language (Ruby) are. The impedance mismatch between languages like Ruby and C is huge, and there you have Ruby, Python, Perl, and JavaScript itself, all implemented in C.
Implementing Ruby in JavaScript should be orders of magnitude easier than doing so in a lower level language. To your advantage, you have that much of Ruby and Ruby's standard library are written in Ruby itself, so once you get a basic interpreter going, things should gradually be more and more downhill.
Implementing an efficient Ruby interpreter in JavaScript may be harder, but it's still possible. You may end up translating Ruby to JavaScript so the excellent optimizers available can kick in.
So, do not think about the differences between Ruby and JavaScript. Take a look at the standard implementation of Ruby, and think about how you would implement that in JavaScript.