是JVM的“下一个装配”？我希望不是。（repost)

This is a transplant from the original Irrational Exuberance, and was written in mid 2007: nearly two years ago.

原始标题是“是Java”下一个装配“？”。一两年或两两个人指出，JVM比Java更合适。迟到总比不到好，对吧？

Recently I have been looking at a number of languages built on top of the JVM, and pondering their allure. I was planning on writing an article examining the code needed to speak between several of these languages and Java, but after finishing it, I realized it was an awful article, so I scrapped it.Instead, I ended up thinking about the difficulties facing these languages, what they us as programmers, and how they will fit into the cycle of language development.

Advantages of JVM based languages

Access to Java libraries

This is the favorite explanation for why we ought to love JVM-based languages: they can use the plethora of Java libraries that--like low hanging fruit--are begging to be picked.For languages that are new (Scala), or have small user bases (Common Lisp), I think that this is a huge boon (one which Scala takes complete advantage of, and CL essentially has not (ABCL对于严肃的使用仍然过于不成熟））。对于许多其他语言，它实际上它实际上将您远离为您的语言编写的最佳工具和图书馆（尽管这可以克服，与JRuby逐渐发展到在Rails上运行Ruby的点）。我认为很多Java库都可以虽然有点笨拙，但此时，努力在Java库周围创建语言适当的包装。Scala - 我坚持认为是最好的JVM语言迄今为止 - 在常用的库上做了一个相当好的工作;他们为JUnit，Swing Gragnics库和其他库创建了Scalaesque包装器。但是，我想看看其他语言更多，因为它可能令人不安地切换到程序编程模式以与Java库一起播放。

‘Free’ speed improvement as JVM improves

另一个常见的上行程序是，随着JVM提高效率，语言将获得“免费”速度改进。我对此持怀疑态度，因为我看到JVM与热点添加的东西越来越复杂，并且这些增加的复杂性将有助于精细调整Java性能，但可能很容易伤害在JVM上建立的其他语言的性能。这个论点是没有与将代码编译为C，然后调整C编译器将继续提高，因此您的代码会随着时间的推移而变得更快。这是真的，但GCC可能不是让你的语言比C（看着你Python）的12次速度的瓶颈。

Downsides of JVM

Some language mix poorly with Java

Java侧重于两个范式：程序和面向对象。当我在多种语言中进行了多种语言审查了语言时，它变得相当明确，这种语言是面向对象的，程序与Java很好，其他语言也没有。让我和每个营地的一个例子澄清（亲切冠军是Jython，竞争“我们在这里不服务于”代表：SISC计划）。

SISC Scheme

Jython

Jython代码几乎是我们可能expect from in CPython, you’re just playing around with some objects you’ve imported from somewhere else. Fairly clean, and easy to understand: its intuitive.The SISC Scheme stuff pretty much blows my mind. It is coercing Scheme into a procedural language, and I find it completely unintuitive, and downright difficult to use (I repeatedly failed to get the to initialize with a value). My point of these two examples being that languages are designed with some specific techniques or paradigms in mind, and languages that were not designed with the same paradigms as Java, are likely to be strange bedfellows.此处还有重要的是，具有非常不同的概念和对象方向实现的语言兼容兼容性（原型化，泛型，ET）。

Certain functionality is precluded by Java technology

This is a relatively minor complaint, but the JVM is simply incapable of performing some operations that a C compiler can perform. Much of this is the result of the safety and security checks built into the JVM, which is a good thing, but its still a limit on the potential power of a language built on top of it.A fairly obvious example of this (although not particularly fatal) is that Java’s interface with filesystems is pretty limited compared to many languages that are linking into the JVM. Thus you’ll have a lot more difficulty with some scripting tasks in Jython than you would in Python.

Execution speed is often worse (but not always)

For the most part, JVM based versions of languages are much slower than the C based implementations. This is true for both Python/Jython and Ruby/JRuby. This is likely the consequence of the JVM based projects being younger and less mature than those based on C. These differences may eventually be resolved, but that remains to be seen.Scala is a real exception here, it has no C based implementation (initially they intended to have a .NET version too, but I believe their .NET implementation is lagging a ways behind), and runs just as quickly as Java does, despite having numerous advantages (of which its syntax may or may not be one).

应用分布更复杂

Much like interpreted languages that depend on an interpreter, basing your language on the JVM means you’ll have to either bring your selected JVM with you (bulky), or deal with the hassle of integrating with non-standardized user setups by trying to use their already existing JVM.Even installing the languages themselves can be an exercise in voodoo. Jython and Scala both installed easily, but I fought with JRuby for about half an hour and couldn’t get it to stop throwing an error message (built from trunk, and also downloaded a prebuilt version, both had the same complaint).(Personally I lean more towards the “if you need it, take if with you” philosophy embodied by Py2App, which brings your interpreter and any needed modules along with it. This bloats program size, but it allows things to just work, which is really important when packaging products for non-gurus.)

Inevitable idiosyncrasies

There is a catch-all type category, but all of the projects implementing their languages using the JVM have a lot of errata and little technicalities that can bite you when you if you don’t read about them ahead of time. Admittedly,alllanguage implementations have these little potholes for you to fall into, but JVM issues are often more subtle (or limiting) than those in traditional C implementations.

Consequences of JVM Languages

我看到这一趋势的最大后果是在JVM上基于JVM的语言是Java组件正在被越来越多地视为通过更具表现力的语言粘在一起的块;Scala / Jython / JRuby是绑定它们的一个环，并且java库仅存在于绑定。这似乎似乎是自我打败的。如果使用魔法脚本语言魔法魔法魔法库的这种方法是真正的优选，那么人们将停止在Java中写作，并将原材料从将滞纳出来，这些语言将再次偏离Java和the flow of new Java libraries will be reduced (programmers will prefer the newer, more expressive languages), and all of this new code won’t be able to talk (can we put out a bounty for a Jython to JRuby bridge? anyone?). Thus, languages built on the JVM strike me as being parasites riding the wave of Java code, but in the end will hear their own dirges not long after Java’s.We can see here the evolution of new languages over time: a new language arrives that can take advantage of existing languages. Then other languages arise that also take advantage of the existing languages, and gradually programming in the existing languages slows to a trickle. Now we find ourselves at the beginning of a new cycle, where yet another language arises that can take advantage of the most abundant libraries and resources, but these languages too will come to an end.The only escape I see to this cycle is to focus on building languages with robust foreign function interfaces that are flexible enough to incorporate new languages that don’t even exist at the time when the FFI is designed and implemented. Essentially, we need to ensure that these new languages can talk双向with the languages they siphon off, otherwise they will only promote slow deaths and recurring cycles.