Walter Bright Wrote:

> Roberto Mariottini wrote:
> > David Brown wrote:
> >> On Sun, Oct 21, 2007 at 10:08:26PM -0700, Walter Bright wrote:
> > [...]
> >>> That isn't an advantage of the VM. It's an advantage of a language that has no implementation-defined or undefined behavior. Given that, the same portability results are achieved.
> >>
> >> It's still a VM advantage.  It helps the model where there are many developers who only distribute binaries.  If they are distributing for a VM, they only have to distribute a single binary.  Otherwise, they still would have to recompile for every possible target.
> > 
> > And not only that: if my product is compiled for Java-CLDC it will work on any cell phone that support CLDC, based on any kind of processor/architecture, included those I don't know of, included even those that today don't exist and will be made in the future.
> 
> Javascript is distributed in source code, and executes on a variety of machines. A VM is not necessary to achieve portability to machines unknown. What is necessary is a portable language design.

Imagine it as a compatibility layer or a shared library. If my OS supports POSIX I can develop for POSIX. If I develop for windows as well I have to learn and use other APIs. A VM is just a special kind of API that provides a language backend and interpreter.

Bruce Adams wrote:
> Imagine it as a compatibility layer or a shared library. If my OS
> supports POSIX I can develop for POSIX. If I develop for windows as
> well I have to learn and use other APIs. A VM is just a special kind
> of API that provides a language backend and interpreter.

It can be thought of that way, it's just entirely unnecessary to achieve those goals, and throws in a bunch of problems:

1) perennial performance issues
2) incompatibility and inoperability with native languages
3) gigantic runtimes needed

On Mon, 22 Oct 2007 21:19:30 +0300, Walter Bright <newshound1@digitalmars.com> wrote:

> 3) gigantic runtimes needed

IMO it's better to have one copy of a gigantic runtime than having parts of it statically linked in every EXE, causing lots of repeating code in a product with lots of binaries (such as an operating system). .NET executables are much smaller compared to most native executables (where the runtime is statically linked) - so, knowing that .NET will only gain more popularity in the future, I find a one-time 20MB download preferred to re-downloading the same components with every new program. Now that Microsoft is including it in their new operating systems, Vista users will just benefit from a smaller download size.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

On 10/22/07, Walter Bright <newshound1@digitalmars.com> wrote:
> 3) gigantic runtimes needed

This one is the killer for me. Java is huge. Net is even bigger. I'm just not interested in putting that much bloat onto my machine just to run the odd one or two programs.

Walter Bright Wrote:

> Bruce Adams wrote:
> > Imagine it as a compatibility layer or a shared library. If my OS supports POSIX I can develop for POSIX. If I develop for windows as well I have to learn and use other APIs. A VM is just a special kind of API that provides a language backend and interpreter.
> 
> It can be thought of that way, it's just entirely unnecessary to achieve those goals, and throws in a bunch of problems:
> 
> 1) perennial performance issues

The difference is what you are optimising the performance of. A dynamic language using a VM is optimising the programmers performance by allowing them to skip the compilation step at the expense of slower code.

> 2) incompatibility and inoperability with native languages

This is partly by design. A VM operating as a sandbox should not be able to go down to the hardware level.
However I think good interoperability has been demonstrated. Most scripting languages sport a way of writing extensions. These must be executed by the VM somehow. And then there's SWIG for automating the generation of wrappers.

> 3) gigantic runtimes needed

An interpreter itself is relatively small. I can only assume that a lot of the bloat is down to bad coding. If you look at games these days they weigh in at a ridiculous 4Gb install. No amount of uncompressed data for performance gain excuses that. I suspect its the same sloppy coding for VMs on a smaller scale. It would not surprise me to see much smaller (and more elegantly designed) run-times on devices such as PDAs where the bloat cannot be tolerated.

<asbestos suit>
I wonder if the compile time side of D might benefit from running inside a VM when people start to do really evil and complicated things with it.
</asbestos suit>

Vladimir Panteleev wrote:
> On Mon, 22 Oct 2007 21:19:30 +0300, Walter Bright
> <newshound1@digitalmars.com> wrote:
> 
>> 3) gigantic runtimes needed
> 
> IMO it's better to have one copy of a gigantic runtime than having
> parts of it statically linked in every EXE, causing lots of repeating
> code in a product with lots of binaries (such as an operating
> system). .NET executables are much smaller compared to most native
> executables (where the runtime is statically linked) - so, knowing
> that .NET will only gain more popularity in the future, I find a
> one-time 20MB download preferred to re-downloading the same
> components with every new program. Now that Microsoft is including it
> in their new operating systems, Vista users will just benefit from a
> smaller download size.

This problem is addressed by DLLs (Windows) and shared libraries (Linux).

Bruce Adams wrote:
> Walter Bright Wrote:
> 
>> Bruce Adams wrote:
>>> Imagine it as a compatibility layer or a shared library. If my OS
>>>  supports POSIX I can develop for POSIX. If I develop for windows
>>> as well I have to learn and use other APIs. A VM is just a
>>> special kind of API that provides a language backend and
>>> interpreter.
>> It can be thought of that way, it's just entirely unnecessary to
>> achieve those goals, and throws in a bunch of problems:
>> 
>> 1) perennial performance issues
> 
> The difference is what you are optimising the performance of. A
> dynamic language using a VM is optimising the programmers performance
> by allowing them to skip the compilation step at the expense of
> slower code.

I bet D compiles faster to native code <g>. In any case, I was talking about performance of apps, not the edit/compile/debug loop.

>> 2) incompatibility and inoperability with native languages
> 
> This is partly by design. A VM operating as a sandbox should not be
> able to go down to the hardware level. However I think good
> interoperability has been demonstrated. Most scripting languages
> sport a way of writing extensions. These must be executed by the VM
> somehow. And then there's SWIG for automating the generation of
> wrappers.

VMs go through some sort of marshalling and compatiblity layer to connect to the outside world. Native languages can connect directly.


>> 3) gigantic runtimes needed
> 
> An interpreter itself is relatively small. I can only assume that a
> lot of the bloat is down to bad coding. If you look at games these
> days they weigh in at a ridiculous 4Gb install. No amount of
> uncompressed data for performance gain excuses that. I suspect its
> the same sloppy coding for VMs on a smaller scale. It would not
> surprise me to see much smaller (and more elegantly designed)
> run-times on devices such as PDAs where the bloat cannot be
> tolerated.

The reason the gigantic runtimes are needed is because the VM has to carry around with it essentially an entire small operating system's worth of libraries. They all have to be there, not just the ones the app actually uses. The VM winds up duplicating much of the functionality of the underlying OS APIs.

> <asbestos suit> I wonder if the compile time side of D might benefit
> from running inside a VM when people start to do really evil and
> complicated things with it. </asbestos suit>

I don't think D compile times have been a problem <g>.

On Tue, 23 Oct 2007 00:56:28 +0300, Walter Bright <newshound1@digitalmars.com> wrote:

> Vladimir Panteleev wrote:
>> On Mon, 22 Oct 2007 21:19:30 +0300, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> 3) gigantic runtimes needed
>>
>> IMO it's better to have one copy of a gigantic runtime than having parts of it statically linked in every EXE, causing lots of repeating code in a product with lots of binaries (such as an operating system). .NET executables are much smaller compared to most native executables (where the runtime is statically linked) - so, knowing that .NET will only gain more popularity in the future, I find a one-time 20MB download preferred to re-downloading the same components with every new program. Now that Microsoft is including it in their new operating systems, Vista users will just benefit from a smaller download size.
>
> This problem is addressed by DLLs (Windows) and shared libraries (Linux).

Except, they're not really as easy to use.

With .NET, you can derive from a class in a compiled assembly without having access to the source. You just add the assembly in the project's dependencies and import the namespace with "using". In C, you must use the included .h files (and .h files are a pain to maintain anyway since you must maintain the declaration and implementation separately, but that's not news to you). You must still use .lib and .di files with D and such - although they can be automated in the build process, it's still a hassle.

Besides that, statically linking in the runtime seems to be a too common practice, as "DLL hell" has been a discouragement for dynamically-linked libraries in the past (side-by-side assemblies is supposed to remedy that though). I guess the fault is not in the DLLs themselves, it's how people and Microsoft used them...

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

Vladimir Panteleev wrote:
> Except, they're not really as easy to use.
> 
> With .NET, you can derive from a class in a compiled assembly without having access to the source. You just add the assembly in the project's dependencies and import the namespace with "using". In C, you must use the included .h files (and .h files are a pain to maintain anyway since you must maintain the declaration and implementation separately, but that's not news to you). You must still use .lib and .di files with D and such - although they can be automated in the build process, it's still a hassle. 
> 
> Besides that, statically linking in the runtime seems to be a too common practice, as "DLL hell" has been a discouragement for dynamically-linked libraries in the past (side-by-side assemblies is supposed to remedy that though). I guess the fault is not in the DLLs themselves, it's how people and Microsoft used them... 
> 

That is correct, but the obvious solution to that problem is to support the OO paradigm in dynamic linking. That is, we don't need a VM, we need DDL.
Had C++ standardized it's ABI, this problem would probably not exist today.

Walter Bright wrote:
> This problem is addressed by DLLs (Windows) and shared libraries (Linux).

I wanted to ask long time ago, will D-runtime be available as dll/so?

Sorry if this was asked/answered before, I didn't manage to find this.

-- serg