D vs. C#

Walter Bright newshound1 at digitalmars.com
Mon Oct 22 14:54:40 PDT 2007


Vladimir Panteleev wrote:
> On Mon, 22 Oct 2007 05:19:39 +0300, Walter Bright
> <newshound1 at digitalmars.com> wrote:
> 
>> I've never been able to discover what the fundamental advantage of
>> a VM is.
> 
> Some of the things which are only possible, or a good deal easier to
> use/implement with VMs:
> 
> 1) code generation - used very seldomly, it might be used for
> runtime-specified cases where top performance is required (e.g.
> genetic programming?)

Are you referring to a JIT? JITs aren't easier to implement than a 
compiler back end.


> 2) VMs make modularity much easier in that you don't have to
> recompile all modules ("plugins") on all platforms, which is often
> not possible with projects whose core supports many platforms, but
> most developers don't have access to all supported platforms.

Problem is solved by defining your ".class" file to be compressed source 
code. Dealing with back end bugs on platform X is no different from 
dealing with VM bugs on platform X. Java is infamous for "compile once, 
debug everywhere".


> 3) very flexible reflection - like being able to derive from classes
> in other modules. Though this can be done in native languages by
> including enough metadata, most compiled languages don't.

I think this is possible with compiled languages, but nobody has done it 
yet.


> 4) compilation is not a simple process for most computer users out
> there.

Since the VM includes a JIT (a compiler) and runs it transparently to 
the user, there's no reason that compiler couldn't compile source code 
into native code transparently to the user.

 > If you want to provide a simple, cross-platform end-user
 > application, it's much easier to use a VM - the VM vendor has taken
 > care of porting the VM to all those platforms,

And the language vendor would have taken care of getting a compiler for 
those platforms!

 > and you don't need to
 > bother maintaining source code portability, make/autoconf/etc. files,
 > and compilation instructions (dependencies, etc.) (ok, most computer
 > users out there use Windows, and many non-Windows users know how to
 > compile a program, but the point stands :P)

This can be automated as well. BTW, non-programmers run compilers all 
the time - after all, how else could they run a javascript app?

> 5) it's much easier to provide security/isolation for VM languages.
> Although native code isolation can be done using hardware, it's
> complicated and inefficient.

The virtualization hardware works very well! It's complex, but it is far 
more efficient than a VM is. In fact, you're likely to be running on a 
hardware virtualized machine anyway!


> This allows VM languages to be safely
> embedded in places such as web pages (Flash for ActionScript, applets
> for Java, Silverlight for .NET).

It is not necessary to have a VM to achieve this. If you design a 
language that does not have arbitrary pointers, and you control the code 
generation, you can sandbox it in software every bit as effectively. 
This is why, for example, the Java JITs don't compromise their security 
model.



More information about the Digitalmars-d mailing list