5 ms·

The future is languages that target a VM I hope not. You may be predicting the future, and there are many indicators pointing that way, but I hope you're wrong

The future is languages that target a VM I hope not. You may be predicting the future, and there are many indicators pointing that way, but I hope you're wrong. VM design is never 100% language-neutral. Targeting existing VMs means inevitably accepting VM limitations and letting some of the original language design choices go. Even things like float point arithmetics, threading and exceptions support are pretty much dictated by your choice of VM. JRuby's team has been constantly struggling with JVM internals [and still couldn't get continuations] and Ruby on LLVM was considered by many to be too difficult to implement. And Ruby isn't very unconventional. Furthermore, commercial VMs tend to be heavy platform-dependent pigs and by targeting one of them you're inevitably denying your language the right to be called "general purpose". By platform dependence I mean that Ruby.NET has to deal with a single "system instance" of .NET, assembly cache and other crap, i.e. things outside of language designer's and software author's control. And finally, you will never be able to port your language to platform X if your favorite VM isn't available there. I can run C and Python programs on my router. C# or Java? Nope.

thwarted 18y ago
"VM design is never 100% language-neutral." The goal for VMs should be to create a generic enough base machine infrastructure such that you end up with the same capabilities and flexibility that the x86, PPC or any other hardware/microcode based architecture provides. VM design may not be language neutral, then maybe some VM designers could learn something from hardware/chip designers. The very reason we're having this discussion is because ANY language can be implemented on ANY of the general purpose hardware architectures available. The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. Associating a VM with a runtime also confuses the technologies; admittedly this is often done because the company pushing their VM product has a vested interest in also providing developers with the tools and the libraries and the UI they program to.
- ars 18y ago
  Second system syndrome? You are reimplementing x86 - with no gain. Just use the actual x86 language. Or if you need multiple machines use C. C is your new VM programming language.
  - eru 18y ago
    GHC actually moved away from using C as a target language. They call it a dead end for whatever reason. (They seem to be going to C--.)
- blasdel 18y ago
  The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. That's just superficial stuff -- the real VM language constraints are things like: calling conventions, type-checking, data structure semantics (esp objects), GC, and module interfaces. These are the kinds of things you want to have shared among languages if you want a useful multi-lang VM. Otherwise what's the point?
  - eru 18y ago
    Type-Checking in the VM? One would have to think hard to accomodate a diverse range of type systems on this level. (And the Haskell guys keep expanding their type systems all the time.)
    - blasdel 18y ago
      "Type-Checking in the VM" means support for runtime type-checks, which can take several forms. In Haskell, all that type-checking is happening only in the early stages of the compiler -- and then the types are erased in the later stages.
  - thwarted 18y ago
    See, but C, and the x86 architecture, has none of that, or it all can be changed (like calling conventions), and yet all languages and VMs can be implemented in C. Despite the explicit lack of support for those things, many C libraries are available with specific language bindings. That being said, those things can be _defined_ for a VM that still uses a flat address space and direct memory manipulation model of the x86 architecture. There is no support for objects or garbage collection or module interfaces in assembly or C, yet those things exist on top of it in languages that are implemented in C and run on x86 (or any usable architecture). There has to be a superset of many languages' conventions that can be used to define the semantics of calls, types, data structures, objects, garbage collection, modules, dynamic dispatch. This already exists somewhat as the ELF (and other) executable formats for things written in C.

thwarted 18y ago

"VM design is never 100% language-neutral." The goal for VMs should be to create a generic enough base machine infrastructure such that you end up with the same capabilities and flexibility that the x86, PPC or any other hardware/microcode based architecture provides. VM design may not be language neutral, then maybe some VM designers could learn something from hardware/chip designers. The very reason we're having this discussion is because ANY language can be implemented on ANY of the general purpose hardware architectures available. The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. Associating a VM with a runtime also confuses the technologies; admittedly this is often done because the company pushing their VM product has a vested interest in also providing developers with the tools and the libraries and the UI they program to.

ars 18y ago
Second system syndrome? You are reimplementing x86 - with no gain. Just use the actual x86 language. Or if you need multiple machines use C. C is your new VM programming language.
- eru 18y ago
  GHC actually moved away from using C as a target language. They call it a dead end for whatever reason. (They seem to be going to C--.)
blasdel 18y ago
The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. That's just superficial stuff -- the real VM language constraints are things like: calling conventions, type-checking, data structure semantics (esp objects), GC, and module interfaces. These are the kinds of things you want to have shared among languages if you want a useful multi-lang VM. Otherwise what's the point?
- eru 18y ago
  Type-Checking in the VM? One would have to think hard to accomodate a diverse range of type systems on this level. (And the Haskell guys keep expanding their type systems all the time.)
  - blasdel 18y ago
    "Type-Checking in the VM" means support for runtime type-checks, which can take several forms. In Haskell, all that type-checking is happening only in the early stages of the compiler -- and then the types are erased in the later stages.
- thwarted 18y ago
  See, but C, and the x86 architecture, has none of that, or it all can be changed (like calling conventions), and yet all languages and VMs can be implemented in C. Despite the explicit lack of support for those things, many C libraries are available with specific language bindings. That being said, those things can be _defined_ for a VM that still uses a flat address space and direct memory manipulation model of the x86 architecture. There is no support for objects or garbage collection or module interfaces in assembly or C, yet those things exist on top of it in languages that are implemented in C and run on x86 (or any usable architecture). There has to be a superset of many languages' conventions that can be used to define the semantics of calls, types, data structures, objects, garbage collection, modules, dynamic dispatch. This already exists somewhat as the ELF (and other) executable formats for things written in C.