新动态编程语言的后端选择？
我一直在开发一个 Smalltalk 变体，只是为了它的乐趣，我想知道在针对后端时， stackoverflowers 会选择什么。 这些是我当前的考虑因素：
.NET、JVM：这两个 VM 主要用于静态类型语言，我认为很难针对像 Smalltalk 这样的动态语言。
Python（作为源代码）：似乎是最简单的方法。 另外，如果我可以发出 Python 字节码，那就更好了，但它没有像其他 VM 的 AFAIK 那样得到很好的记录（需要挖掘 Python 的源代码以获取详细信息！）。
自制解释器：不可能，因为它没有乐趣:-)
LLVM、NekoVM、Parrot 是我正在检查的其他选项。 您对此有何看法？
I've been developing a Smalltalk variant for just the fun of it and I wonder what would be a fellow stackoverflowers choice when it comes to targeting a back-end. These were my current considerations:
.NET, JVM: These two VM's are mainly for statically typed languages and I assume it would be quite hard to target such a dynamic language like smalltalk.
Python (as source code): Seems to be the simplest way. Also it would be better if I could emit Python bytecode but it's not well documented as other VM's AFAIK (Need to dig Python's source code for details!).
Self made interpreter: Out of the question as it's no fun :-)
LLVM, NekoVM, Parrot are other options I'm checking out. What would be your take on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
不要这么快就低估 .NET 或 JVM。 正在为两者开发动态语言（例如，JVM 上的 Groovy、JRuby、Jython；.NET 上的 IronRuby、IronPython），并且 .NET 正在获得“DLR”——动态语言运行时。 （有关更多详细信息，请参阅 Jim Hugunin 的博客。）
Don't discount .NET or the JVM so quickly. Dynamic languages are being developed for both (e.g. Groovy, JRuby, Jython on the JVM; IronRuby, IronPython on .NET) and .NET is gaining the "DLR" - Dynamic Language Runtime. (See Jim Hugunin's blog for more details.)
Parrot 真的很酷，即使他们还没有发布任何“真正的”代码。 但由于该项目只是为了好玩，所以这不应该阻止你：D。
Parrot is really cool, even if they haven't shipped any "real" code yet. But since the project's just for fun, that shouldn't stop you :D.
我会选择JVM，但主要是因为我熟悉它。
JVM 的客观原因是：支持主要平台、库较多、性能良好（在您给出的选择范围内）它可能具有最佳性能）。
.Net 在 Windows 上运行效果最佳。 如果您选择它，您应该在 Mono 上进行测试，以使其更加平台中立。
Python 似乎也是一个不错的选择。 但我认为对于 JVM 有更多的库可用。
Parrot 在我看来太新鲜了，它需要一些时间才能成熟。 但这是未来的一个有趣的选择。
其他选择对我来说是新的，我会看一下。
I would choose the JVM, but mainly because I'm familiar with it.
Objective reasons for JVM are: main platforms are supported, many libraries and good performance (within the choices you have given it may have the best performance).
.Net works best on Windows. If you choose it, you should test on Mono to be more platform-neutral.
Python seems a good choice as well. But I think for the JVM more libraries are available.
Parrot is in my opinion too fresh, it needs some time to mature. But an interesting alternative for the future.
The other choices are new to me, I will take a look at them.
既然您正在尝试实现 Smalltalk，为什么不考虑为 Ruby 设计一个受 Smalltalk 启发的 VM，例如 YARV 甚至 鲁比尼乌斯。 两者都受到smalltalk的启发，并旨在实现高性能。 YARV 将成为新的标准 Ruby VM。
Since you are trying to implement Smalltalk, why not consider one of smalltalk-inspired VMs for Ruby like YARV or even rubinius. Both are smalltalk-inspired and aim to be high-performance. YARV will be the new standard Ruby VM.
使用 Parrot 的一个优点是它附带了大量示例语言，包括名为 ChitChat 的 Smalltalk 变体。 所以你可以用它作为参考，看看其他人是如何在 Parrot 上实现类似的语言的。
One adavantage of using Parrot is that it ships with tons of example languages, including a Smalltalk variant called ChitChat. So you can use that as a reference to see how someone else has implemented a similar language on Parrot.
您可能想看看PyPy - 而这个项目存在是为了用 Python（的子集）实现 Python 语言，他们采用的方法允许多个前端和多个后端（我认为包括 CLR、JVM、LLVM、C，甚至 Smalltalk 和 JavaScript）。 例如，致力于 JIT 使用Prolog作为前端语言，CLR作为后端完成。 因此，您可能加入了实现 Smalltalk 的队伍，后来发现您也在不知不觉中帮助其他人实现了 Prolog...:-)
You might want to have a look at PyPy -- while this project exists to implement the Python language in (a subset of) Python, the approach they are taking allows multiple front-ends and multiple back-ends (including CLR, JVM, LLVM, C, and even Smalltalk and JavaScript, I think). For example, work on the JIT has been done using Prolog as the front-end language and CLR as the back-end. So you might join the party to implement Smalltalk and later discover you've also helped someone else implement Prolog without knowing it... :-)
Factor (http://factorcode.org/) 可能为此提供一些有用的功能。
Factor (http://factorcode.org/) may offer some useful features for this.
如果这是为了好玩，为什么不从开源的 Squeak 代码库开始，然后修改它。 Smalltalk 应该有一个小的运行时间，并且您的小型有趣变体可以从 squeak 的引导环境开始，该环境几乎是微观的，并从那里构建。
我反对 .NET 和 JVM 的一大原因是它的尺寸巨大。 看看 Squeak 中运行时“操作系统到 Smalltalk”阻抗匹配层有多小。
有趣的项目不应该是……有趣吗？ 吱吱声有很多含义，商务活动不是其中之一，但绝对是有趣的。
If this is for fun, why not start with the codebase for Squeak, which is open source, and modify it. Smalltalk should have a small runtime, and your small fun variant could start with the bootstrap environment from squeak, which is nearly microscopic, and built up from there.
My big thing against .NET and the JVM is the sheer huge size. Look how small the runtime "operating system to smalltalk" impedence-matching-layer is in Squeak.
Shouldn't fun projects be, well...... FUN? Squeak is many things, businesslike is not one of them, but FUN ... definitely.
JVM 作为首选。 从第一天起，它将获得广泛的图书馆支持。 看看这对 Clojure 有何好处。
另外，LLVM 可能是一个有趣的选择，但我不确定它的“证明”程度如何，因为我无法使用 LLVM 后端实现成熟的语言实现。
我会避免使用.NET。 这将使围绕您的新语言聚集社区和支持变得更加困难，而且您很快就会需要它。 此外，它不是跨平台的。
无论你选择什么，你都会从中学到很多东西。
JVM as first choice. It would allow for a wide library support from the day one. See how that benefited Clojure.
Also, LLVM might be interesting choice, but I'm not sure how "proven" it is, since I can't have a mature language implementation with LLVM backend.
I would avoid .NET. It would make it harder to gather community and support around the your new language, and you are going to need it soon. Also, it is not cross-platform.
Whatever you choose, you will learn a lot by doing so.
与 .Net 相比，JVM 更稳定、文档更齐全，并且通常不太可能成为移动目标
此外，如果您采用开源，您更有可能找到可以帮助您的人。 .Net 人才确实很稀缺，而且大多数人都为 Microsoft 工作，因此他们不太可能有时间提供帮助。
JVM is more stable, well documented, and in general less likely to be a moving target than .Net
Also you're more likely to find people that can help you out if you go open source. With .Net talent is really scarce, and most work for Microsoft, so they won't likely have the time to help out.
.NET 现在作为 DLR，位于动态语言的 CLR 之上。
.NET as the DLR now that sit on top of the CLR for Dynamic language.
在 .Net 上进行操作，毕竟您只是为了好玩。 所以让它有点挑战性。 任何发现都可以报告给 Microsoft，以改进 DLR 及其支持的语言。
Do it on .Net, after all you want to do it for fun. So make it a bit challenging. And any findings then can be reported to Microsoft, for improvement in DLR and the languages it supports.
如果您打算考虑使用 .Net，请查看 Beautiful Code——其中有一篇关于在 .Net CLR 上进行动态代码生成的文章。
If you're going to look at using .Net, have a look in Beautiful Code -- there's an essay in it about doing dynamic code gen on the .Net CLR.
绝对是使用动态语言运行时的.Net。 当您完成时，您的对象将可以直接被 C# 和 V.Net 用户使用（您打算发布一些东西吗？:-）
特别是，在 SilverLight 中的简化 .Net 下运行的目标这样您就可以获得最新的网络丰富的用户界面支持。
Definitely .Net using the Dynamic Language Runtime. Your objects will be usable directly by C# and V.Net users by the time you're finished (you are intending to ship something? :-)
In particular, target running under the reduced .Net in SilverLight so you get the latest web rich UI buy-in.