There are some subtle but very important points in this article. If you've ever found yourself thinking that a generic bytecode VM could be a panacea, you should definitely read this.
We were frequently asked why the Dart VM is not bytecode based. This article tries to answer the question.
7 plus ones
Shared publicly•View activity
- "The case for a language VM" does not make much sense for me as you can just include the compiler. That's what Smalltalk does, as it is generally bytecode based.Dec 21, 2011
- : The issue at hand is not whether the system uses a bytecode representation internally (like many Smalltalk implementations do). Rather, the question is whether the VM exposes a "generic" bytecode representation as its source language (like the JVM and CLR do). The point of the article is that it's not practical to expose a fully-generic bytecode representation without baking in assumptions about the language that it's meant to serve (if you want the VM to be fast).
Smalltalk bytecode is a case-in-point -- its sole purpose in life is to serve Smalltalk-the-language, and it would be a very poor target for most other languages.Dec 21, 2011
- OK, understood, can agree on that.
But how about implementing a mechanism to handle unknown script tags using native client modules and using that for Dart?Dec 21, 2011
- : The problem with NaCl is that, while it's awesome for compiled C++ code, it's far from a panacea for dynamic VMs, because JITting carries a significant cost in the NaCl sandbox (I suspect it would be even worse in pNaCl, because of the need to go through LLVM as well). This would also imply shipping a full copy of the VM (which can easily be multiple megabytes) with client apps.Dec 21, 2011
- Pity. Shipping the VM with client apps could be avoided by some sort of global native client library repository mechanism but speed is of course critical. Would love to see a language neutral web instead of a one language web (or a two language web).Dec 21, 2011
- I'd prefer if there were a much more generic mechanism for shipping code to web browsers, but the more I look at the problem, the more it appears there's no easy solution.
In "native" platforms, this means that you need to be able to make calls to C functions (or Pascal on Windows, but there's not a lot of difference). VM languages like Java, Python, etc. go to a lot of trouble to provide reasonable ways to do this, but they're far from simple or, for that matter, secure.Dec 21, 2011
- Well, hope you'll come up with something ;-)Dec 21, 2011
- sounds like a good ideaDec 29, 2011
Add a comment...