3 ms·

Does building a VM without a language make sense? I don't know of any successful instances of this approach. There are lot of hairy corner cases in languages,

by chubot 9y ago

Does building a VM without a language make sense? I don't know of any successful instances of this approach. There are lot of hairy corner cases in languages, and VMs reflect that. If you build the VM first, those design decisions may not be obvious, or might come to light a lot later. I tried compiling Python code to the Lua VM and found that it is extremely coupled to Lua's semantics. That's even more the case with Python's VM. (for example scope rules, module systems, etc.) I mean, I think you can target one language to the VM for sure. If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes.

DonaldFisk 9y ago
I've developed a few VMs and each was always tied to a specific language or one of its close relatives. The advantages of having a VM is that it's a lot easier to compile to than native code, you can run it on any hardware for which an interpreter has been written, and its object code is a lot smaller. The disadvantage is that the compiled code runs slower. The exception is when someone wants their language to run on an existing VM, e.g. for Java or to run in a web browser, so they compile it to the VM's instruction set. Various languages are compiled onto the JVM, and the same WebAssembly code has to run on any hardware onto which the containing web page has been downloaded, and will run faster than the equivalent JavaScript.
earenndil 9y ago
> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Counterexample: the JVM, which runs quite a few languages, including some that were created without any consideration thereof (python, ruby, lisp, perl).
- lalo2302 9y ago
  > If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Example: Elixir and Erlang on BEAM VM
- chubot 9y ago
  Yeah I think the JVM is a special because of Hotspot -- a state-of-the-art JIT compiler. I'm pretty sure that without a JIT you will not get decent performance on compiling one language to a VM designed for another language. Also, I think the JVM "required" at least one modification for dynamic languages? I recall something about JRuby and invokedynamic bytecode, but I don't know the details: https://www.infoq.com/articles/Invokedynamic-Javas-secret-weapon https://www.infoq.com/articles/Invokedynamic-Javas-secret-we... As another counterexample, I've heard that VB.NET is just C# in a different syntax, more than it is VB6. That is, when it moved to the CLR, the language changed.
  - WorldMaker 9y ago
    VB.NET is more like VB6 than C#. The problems with the vocal minority in the VB6 community not moving to VB.NET had mostly nothing directly to do with the CLR. (The break in backwards compatibility, and inability to just "upgrade" old code, in a language that hadn't a major break since VB3 was more impactful, I think. That was more due to the VB team trying to clean house and remove anti-patterns than the CLR's fault.) The CLR has just as many languages, including dynamic languages, supported as the JVM.
    - meredydd 9y ago
      VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like the JVM.) It is possible to mechanically transform VB.NET code into C# code. Heck, I'd bet they both parse to the same AST. They are very, very similar languages, with the exception of syntax. The upshot is that writing VB.NET involves understanding everything you need to understand to write C#. All the syntax is VB6-flavoured, sure, but it still involves making people learn about classes, this year's flavour of Windows UI components, and so on. What's more, you have to do it all in an industrial-strength IDE, with all the complexity that brings. (Don't get me wrong - Visual Studio is more or less my gold standard for a usable industrial-strength IDE. But if you stand it next to VB6, you'll see how much more you need to understand just to get to editing code is noticeably larger. It can be invisible to people like you or me, who have already absorbed these concepts, but it's real.)
maelkum 9y ago
Hi, Viua VM's developer here. Sure, compiling a language to a VM with mismatched semantics is not a pleasant experience. Viua's execution model of many processes communicating via messages is best suited to Erlang, or other actor model languages.
pjmlp 9y ago
Yes, that is how most mainframes used to work, having a kind of common language environment. Then the applications are either JITed at installation time, or the CPUs are micro-coded, JITing the applications during execution. Burroughs (now Unisys), Xerox PARC machines, ETHZ systems, IBM mainframes.

by chubot 9y ago

DonaldFisk 9y ago

I've developed a few VMs and each was always tied to a specific language or one of its close relatives. The advantages of having a VM is that it's a lot easier to compile to than native code, you can run it on any hardware for which an interpreter has been written, and its object code is a lot smaller. The disadvantage is that the compiled code runs slower. The exception is when someone wants their language to run on an existing VM, e.g. for Java or to run in a web browser, so they compile it to the VM's instruction set. Various languages are compiled onto the JVM, and the same WebAssembly code has to run on any hardware onto which the containing web page has been downloaded, and will run faster than the equivalent JavaScript.

earenndil 9y ago

> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Counterexample: the JVM, which runs quite a few languages, including some that were created without any consideration thereof (python, ruby, lisp, perl).

lalo2302 9y ago
> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Example: Elixir and Erlang on BEAM VM
chubot 9y ago
Yeah I think the JVM is a special because of Hotspot -- a state-of-the-art JIT compiler. I'm pretty sure that without a JIT you will not get decent performance on compiling one language to a VM designed for another language. Also, I think the JVM "required" at least one modification for dynamic languages? I recall something about JRuby and invokedynamic bytecode, but I don't know the details: https://www.infoq.com/articles/Invokedynamic-Javas-secret-weapon https://www.infoq.com/articles/Invokedynamic-Javas-secret-we... As another counterexample, I've heard that VB.NET is just C# in a different syntax, more than it is VB6. That is, when it moved to the CLR, the language changed.
- WorldMaker 9y ago
  VB.NET is more like VB6 than C#. The problems with the vocal minority in the VB6 community not moving to VB.NET had mostly nothing directly to do with the CLR. (The break in backwards compatibility, and inability to just "upgrade" old code, in a language that hadn't a major break since VB3 was more impactful, I think. That was more due to the VB team trying to clean house and remove anti-patterns than the CLR's fault.) The CLR has just as many languages, including dynamic languages, supported as the JVM.
  - meredydd 9y ago
    VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like the JVM.) It is possible to mechanically transform VB.NET code into C# code. Heck, I'd bet they both parse to the same AST. They are very, very similar languages, with the exception of syntax. The upshot is that writing VB.NET involves understanding everything you need to understand to write C#. All the syntax is VB6-flavoured, sure, but it still involves making people learn about classes, this year's flavour of Windows UI components, and so on. What's more, you have to do it all in an industrial-strength IDE, with all the complexity that brings. (Don't get me wrong - Visual Studio is more or less my gold standard for a usable industrial-strength IDE. But if you stand it next to VB6, you'll see how much more you need to understand just to get to editing code is noticeably larger. It can be invisible to people like you or me, who have already absorbed these concepts, but it's real.)

maelkum 9y ago

Hi, Viua VM's developer here. Sure, compiling a language to a VM with mismatched semantics is not a pleasant experience. Viua's execution model of many processes communicating via messages is best suited to Erlang, or other actor model languages.

pjmlp 9y ago

Yes, that is how most mainframes used to work, having a kind of common language environment. Then the applications are either JITed at installation time, or the CPUs are micro-coded, JITing the applications during execution. Burroughs (now Unisys), Xerox PARC machines, ETHZ systems, IBM mainframes.