您如何看待通常编译语言的翻译？

Question

我使用C ++解释器（CINT），我的经历是灾难性的。它充满了bug，strage行为，而不是标准......我得出一个结论：创建一个出生的语言翻译是错误的，因为我认为语言的设计严格限制在事实上它将被解释或编译。

你怎么看？

Answer 1

编译器和解释器之间的唯一区别是性能。当然，一个特定的C ++解释器是错误的，但这并不意味着所有的C ++解释器都必须是错误的。我认为这与C ++是否“意味着”编译（由谁？）有关，而更多地与C ++是一种非常难以编译的语言这一事实​​有关。

（只要我们提出意见，我认为C ++既不应该编译也不应该被解释，而应该翻译成不同的语言。但那只是我。）

Answer 2

  

创建一个天生被编译的语言的解释器是错误的。

不是没有这样的动物。 C ++诞生时是C的预处理器，当它曾经被称为“C with Classes”时。可以编译或解释任何创建的语言，尽管有些动态语言很难有效编译。所以我可能会购买“天生被解释”的想法，但从来没有“天生就被编译”。

更严重的是，创建蹩脚的解释器是错误的，就像创建糟糕的编译器一样。完全停止。

  

您如何看待通常编译语言的翻译？

我用过的最好的系统之一是Saber-C系统：C语言的翻译，你可能会说这是一种可以编译的语言。太棒了。我仍然想念它。

Answer 3

嗯，我的想法是这很有可能。我认为你遇到的是被解释的语言的复杂性。即使在编译时，C ++也有各种边缘条件和其他怪癖，更不用说被解释了。

更简单的语言（想想Boo，F#），虽然是编译语言，仍然可以被解释。

Answer 4

这里的“错误”是创建一个有缺陷的实现（尽管从一个复杂的语言开始是一个坏主意）;拥有可编写脚本的语言确实有一些用户案例，但我的观点是 已经大量的scribt语言与合理的实现在多个平台上。如果我需要一种脚本语言，我可能会想要使用其中一种语言。

另外，IIRC C＃规范要求规范预期与编译器一起使用，但这不是必需的，并且可以使用合法的解释版本。< / p>

Answer 5

如果他们被编写为编译，那么你为什么要逆潮流游泳：）

Answer 6

不是没有错，但你为什么要这样做。像C和C ++这样的语言非常靠近机器。因此，如果您想构建一个解释器，您应该构建一个完整的虚拟机。哪个没有错，但有更多有用的项目。