ruby 在不同集合中的实现
我只是对一个概念感到困惑。我听说过 Ruby 作为一种编程语言。现在，很多公司/个人都开发了JRuby（Java的Ruby实现）和Jython（Python的Ruby实现）。 谁能解释一下，一种编程语言到底如何用另一种编程语言实现？ 如果我说得有道理吗？
是否可以为 Prolog 等任何其他系统开发 Ruby 实现？
谁能解释一下吗？
提前致谢。
I am just confused with a concept. I have been hearing about Ruby as a programing language. Now, many companies/individuals have developed JRuby, which is Ruby implementaion for Java and Jython, which is Ruby implemtation for Python.
Can anyone please explain me, how exactly one programming language can be implemented in another programming language?
If I am making any sense?
Is it possible to develop Ruby implementaiton for any other systems like Prolog?
Can anyone please explain?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编程语言只是您（程序员）和机器之间不同抽象程度的转换器。例如，Ruby 本身是用 C 编写的（就像大多数语言一样，在自我构建之前，即该语言足够强大，可以构建自己），其中 C 代码被编译为可以理解 Ruby 代码的机器代码。它所做的只是从一种范式转换为另一种范式。红宝石-> C->汇编器->处理器指令并再次备份，也具有不同程度的动态性（某些代码是硬编码的，即不会更改或无法处理结构的更改，而其他代码则设计为专门处理动态结构，例如JVM）。但这一切最终都变成了机器代码。 Ruby 是机器代码。 JRuby 是运行在 JVM 上的字节代码，即机器代码。 Ruby 中的字符串是 JRuby 中的字符串，C 中的 char[] 数组是机器代码中的结构化内存位置行。您可以让一组机器代码（抽象地称为“Ruby”）理解其他机器代码（抽象地称为“Ruby 代码”）。
抽象程度越高，范式对其所依赖的技术平台的依赖就越少，而抽象程度越低，范式对其依赖的技术平台就越多。移植软件依赖于在各种平台上可用的堆栈的各个部分。我确信有些平台上没有 Ruby，但如果他们有 C（或者更具体地说，ANSI C，任何平台真正尝试为其创建编译器的第一个语言之一），那么它就是可以为其编译一种（或任何其他语言）（进行一些调整）。这一切都归结为将您的抽象转换为计算机本身可以理解并执行操作的指令。
例如，Java 使用中间层系统（JVM），它是 Java 代码（所有平台都相同）和平台（大多数平台都不同）之间的翻译器。为 JVM 编写 Ruby 解析器只是重新使用 JVM 作为中间层，而不是使用 ANSI C，因此可能更简单一些；如果它运行在 JVM 上，它就可以运行 JVM 可以运行的任何地方，而 JRuby 可以让制作 JVM 的人担心更多平台特定的东西（而且我相信 JVM 本身是用 C 编写的）。
还有另一种看待这个问题的方法，例如使用 JS.Class 之类的东西，它采用了一些范例语言并使其可以用另一种语言使用，因为它们很好/很酷/很时尚。
A programming language is just a translator between you, the programmer, and the machine, to varying degrees of abstraction. For example, Ruby itself is written in C (as most languages are, before they go self-building, ie. where the language is powerful enough to build itself), where the C code is compiled to machine code that can understand Ruby code. What it does is simply to translate from one paradigm into another; Ruby -> C -> Assembler -> processor instructions and back up again, also to varying degrees of dynamics (some code is hard-coded, ie. does not change or can't deal with a change in structure, whilst others are designed to exclusively deal with dynamic structures, like the JVM). But it all ends up as machine code. Ruby is machine code. JRuby is byte code running on the JVM which is machine code. An String in Ruby is a String in JRuby is a char[] array in C is a structured line of memory positions in machine code. You can have a set of machine code (abstractly known as 'Ruby') understand other machine code (abstractly known as 'Ruby code').
The higher the abstraction, the less the paradigms will rely on the technical platform it is on, and the lower the more it relies on it. Porting software relies on various parts of the stack also being available on various platforms. I'm sure there's platforms which hasn't got Ruby on it, but if they've got C on it (or, more specifically, ANSI C, one of the first languages any platform really tries to create a compiler for) then it's possible to compile one (or any other language) for it (with some tweaks). It all comes down to converting your abstractions down to instructions the computer itself can understand and act on.
Java, for example, uses a middle-tier system (the JVM) which is a translator between Java code (same for all platforms) and the platform (mostly different for all). Writing a Ruby parser for the JVM is just re-using the JVM as a middle-tier instead of using ANSI C, and is therefore probably a bit simpler to do; if it runs on the JVM, it can run everywhere the JVM can run, and JRuby can let the people who make the JVM worry about the more platform specific stuff (and I believe the JVM itself is written in C).
There's another way of looking at this, too, for example with something like JS.Class which takes some paradigms from one language and makes them available in another, because they're good / cool / trendy.