Georg Wrede wrote:

>> So I think he's just forgetting (or deliberately ignoring) the fact that someone still has to write that VM and the operating system it runs on, and those better run as fast as possible or no one will care how wonderfully "dynamic" it is.
> 
> Considering that all the languages he talks about still have to be /compiled/ for the VM (JIT or no JIT), I have a hard time seeing the case for VMs being rock-solid and compelling.
> 
> Think about it. If I have a web site where I let viewers run their own code on my server, I could simply provide them with a rigged D compiler. The compiler would (or a preprocessor, it would actually be easier for me) flag no-nos in their source code as errors. No biggie.
> 
> Or I might sandbox the running user binaries.

Or you could just use Java's VM instead of trying to figure out how to make all that work.  I think that's a big part of it.  The Java VM works and is available today, so for people like Steve it makes sense to use it.

> ---
> 
> And then there's the choice nobody seems to suggest: running a VM that uses the processor's own ASM as the VM language. The (e.g. D) compiler would enforce the exclusion of dangerous idioms.

That's kinda what the "virtual appliance" thing is about isn't it? Running an app inside a VMWare instance with some ASM as the VM's native tongue.

--bb

Bill Baxter wrote:
> Georg Wrede wrote:
> 
>>> So I think he's just forgetting (or deliberately ignoring) the fact that someone still has to write that VM and the operating system it runs on, and those better run as fast as possible or no one will care how wonderfully "dynamic" it is.
>>
>> Considering that all the languages he talks about still have to be /compiled/ for the VM (JIT or no JIT), I have a hard time seeing the case for VMs being rock-solid and compelling.
>>
>> Think about it. If I have a web site where I let viewers run their own code on my server, I could simply provide them with a rigged D compiler. The compiler would (or a preprocessor, it would actually be easier for me) flag no-nos in their source code as errors. No biggie.
>>
>> Or I might sandbox the running user binaries.
> 
> Or you could just use Java's VM instead of trying to figure out how to make all that work.  I think that's a big part of it.  The Java VM works and is available today, so for people like Steve it makes sense to use it.

Hmm. I originally took it like he's promoting the VM as /itself/ having properties that make it the superior and Obvious choice. But maybe it's all simply about the Java VM bein easy ubiquitous and mature.

>> And then there's the choice nobody seems to suggest: running a VM that uses the processor's own ASM as the VM language. The (e.g. D) compiler would enforce the exclusion of dangerous idioms.
> 
> That's kinda what the "virtual appliance" thing is about isn't it? Running an app inside a VMWare instance with some ASM as the VM's native tongue.

Pretty close.

"Georg Wrede" <georg@nospam.org> wrote in message news:485A582F.6050103@nospam.org...
>> Or you could just use Java's VM instead of trying to figure out how to make all that work.  I think that's a big part of it.  The Java VM works and is available today, so for people like Steve it makes sense to use it.
>
> Hmm. I originally took it like he's promoting the VM as /itself/ having properties that make it the superior and Obvious choice. But maybe it's all simply about the Java VM bein easy ubiquitous and mature.
>

I could be wrong, but I got the impression that he, like a lot of VM-proponents (but not all!), aren't considering those to be two separate concepts. That is, I suspect they might be confusing "the way things currently are" (ie, "VMs like the JVM have mature sandboxing and runtime reflection today, and such things aren't currently in non-VMs") with "the only way things can be" (ie, "You can't have things like sandboxing and runtime reflection without a VM").

Georg Wrede wrote:
> Hmm. I originally took it like he's promoting the VM as /itself/ having properties that make it the superior and Obvious choice. But maybe it's all simply about the Java VM bein easy ubiquitous and mature.

I see the advantage of a VM as being if you're inventing a new language, you don't have to bother writing an optimizer, code generator, or linker.

Of course, LLVM should make that advantage moot as well.

Walter Bright:
> I see the advantage of a VM as being if you're inventing a new language, you don't have to bother writing an optimizer, code generator, or linker.

And often GC, part of the standard library, some/most external modules, DBMS interfaces, GUI widgets, etc, too :-) That's why creating a language like Boo on the dotnet was doable by a single person in few months.

Bye,
bearophile

Op Sun, 15 Jun 2008 11:40:33 -0700, schreef Walter Bright:

> Steve also says in his blog that the advantage of VMs is language interoperability. I don't agree, since all you need for interoperability is an ABI. For compiled languages, the C ABI serves just fine, and as long as each language has a way to get at the C ABI, you have language interoperability.

The C ABI isn't really useful if you want (standardised) interoperability on an OO level.

That's where an OO machine design (be it a VM or a physical machine design--I don't care, and I don't see the difference for language designers) can be useful.

E.g., I've been wondering for some time what a hardware design like Linn's Rekursiv[*] could have meant to computer languages if it wouldn't have been killed because of various reasons (mostly financial...).


[*] <http://www.cpushack.net/CPU/cpu7.html>

-- 
JanC