我正在开发一种新语言 . 我最初的目标是为Windows平台编译为原生x86，但现在我有疑问 .
我不能轻易地将每种语言都移植到JVM上;这样做可能会导致语言和设计的微小变化 .
在提出这个问题之后，我甚至怀疑这个决定 . 我现在知道一些"pro" JVM参数 . 最初的问题是：在为新语言创建编译器时，目标JVM是个好主意吗？
更新了问题： What are the disadvantages of targeting the JVM instead of x86 on Windows?
针对JVM是一种非常经过实践检验的方法 . Clojure，Scala，JRuby和many other languages这样做的事实应该会给你一些保证 .
我的总体观点是，JVM可能是目前新/实验语言的最佳目标，特别是如果您希望在利用真正出色的JIT编译器和大量非常强大的库的同时实现跨平台功能 .
话虽如此，我认为针对JVM可能遇到的主要缺点如下：
在字节码级别缺少尾递归支持 . 有很多方法可以解决这个问题（例如，参见Clojure的“复现”特殊形式），但对于某些语言实现，尤其是函数式语言来说，它很烦人 . 最终可能会在未来的Java版本中修复 .
有点明显，但您需要在客户端上安装JVM . 现在通常不是问题，但仍有一些情况可能会很棘手 .
Java中的基元（int，long，float等）与对象系统的其余部分表现不同 . 您可以再次解决这个问题，但对于语言实施者来说，这是一些额外的麻烦 .
一些可能有用/有趣的链接：
ASM bytecode analysis and manipulation framework . 这是一个很棒的工具，我相信这就是Clojure在引擎盖下使用的东西 .
Clojure source code
您可能希望查看目标LLVM而不是JVM . LLVM可用于定位许多体系结构，包括x86 .
可移植性比简单的CPU支持更多，但LLVM可以提供很多帮助，如果您愿意，仍然可以为您提供本机代码 .
如果您为JVM创建一种语言，那么您还可以拥有一个巨大的优势，即您可以在您的语言中使用一个巨大的库 . 如果您为x86编译，则很可能不是这种情况 . 我认为你不可能包括例如没有C语言分析器的语言的C-header .
出于这个原因，Scala，Groovy和其他人都是如此成功 .
在JVM的当前开发阶段，以及支持脚本语言的新增强功能，我只是针对JVM，因为您的语言将比您自己创建的每个运行时库更快地执行 .
如果您很乐意让代码的运行时部分完全依赖于第三方代码并且要求用户安装这些代码，那么您应该只定位JVM，并且JVM将提供您自己无法合理开发的实质性功能或者要求人们为此目的进行扩展（例如C中的OS头文件），并且您对JNI作为本机代码的接口（以及其他托管代码，如.NET）感到满意 .
最终，它完全取决于您可用的资源以及您如何描绘语言互操作 . 如果你打算使用JVM来提供很多功能，并且你很高兴互操作很糟糕，那么就使用它 . 否则，我认为你应该重新考虑 .
4 回答
针对JVM是一种非常经过实践检验的方法 . Clojure，Scala，JRuby和many other languages这样做的事实应该会给你一些保证 .
我的总体观点是，JVM可能是目前新/实验语言的最佳目标，特别是如果您希望在利用真正出色的JIT编译器和大量非常强大的库的同时实现跨平台功能 .
话虽如此，我认为针对JVM可能遇到的主要缺点如下：
在字节码级别缺少尾递归支持 . 有很多方法可以解决这个问题（例如，参见Clojure的“复现”特殊形式），但对于某些语言实现，尤其是函数式语言来说，它很烦人 . 最终可能会在未来的Java版本中修复 .
有点明显，但您需要在客户端上安装JVM . 现在通常不是问题，但仍有一些情况可能会很棘手 .
Java中的基元（int，long，float等）与对象系统的其余部分表现不同 . 您可以再次解决这个问题，但对于语言实施者来说，这是一些额外的麻烦 .
一些可能有用/有趣的链接：
ASM bytecode analysis and manipulation framework . 这是一个很棒的工具，我相信这就是Clojure在引擎盖下使用的东西 .
Clojure source code
您可能希望查看目标LLVM而不是JVM . LLVM可用于定位许多体系结构，包括x86 .
可移植性比简单的CPU支持更多，但LLVM可以提供很多帮助，如果您愿意，仍然可以为您提供本机代码 .
如果您为JVM创建一种语言，那么您还可以拥有一个巨大的优势，即您可以在您的语言中使用一个巨大的库 . 如果您为x86编译，则很可能不是这种情况 . 我认为你不可能包括例如没有C语言分析器的语言的C-header .
出于这个原因，Scala，Groovy和其他人都是如此成功 .
在JVM的当前开发阶段，以及支持脚本语言的新增强功能，我只是针对JVM，因为您的语言将比您自己创建的每个运行时库更快地执行 .
如果您很乐意让代码的运行时部分完全依赖于第三方代码并且要求用户安装这些代码，那么您应该只定位JVM，并且JVM将提供您自己无法合理开发的实质性功能或者要求人们为此目的进行扩展（例如C中的OS头文件），并且您对JNI作为本机代码的接口（以及其他托管代码，如.NET）感到满意 .
最终，它完全取决于您可用的资源以及您如何描绘语言互操作 . 如果你打算使用JVM来提供很多功能，并且你很高兴互操作很糟糕，那么就使用它 . 否则，我认为你应该重新考虑 .