D vs VM-based platforms

[Benji Smith]

BCS wrote:
> Reply to Benji,
> 
> [...]
> 
> Most of your rebuttal basically says that programs in VM can do X 
> without the coder having to do something different than they would if 
> they didn't do X. There is (lots of big problems aside) a simple 
> solution to this problem in native code: Don't allow the coder to NOT do 
> X, requiter that all classes be COM objects, always compile in debugging 
> and profiling symbols, heck maybe even a full net-centric debugger. It 
> seams to me (and I could be wrong) that the way that the VM languages 
> get all of these advantages of these options is by not making them 
> options, they are requirements.
> 
> The only case that all of that doesn't cover is sand boxing. Well, 
> something is going to have to run in native code, so why not make native 
> code safe? Allow a process to span off a thread that is native code but 
> sand boxed: some OS API's don't work, it has a Read Only or no access to 
> some part of ram that the rest of the process can access. In short If 
> security is such a big deal, why is the VM doing it instead of the OS?


Sure. Fair enough. You *could* maybe do all of that stuff with native 
code, if only someone had ever implemented it.

...Shrug...

Rather than speculating on what's theoretically possible in a natively 
compiled platform, I'm pointing out some of the advantages that exist 
*today* in VM-based platforms.

I never claimed those advantages outweighed the considerable advantages 
of native compilation. I'm just saying...there are some features that 
are *currently* being routinely provided in VM platforms that don't yet 
exist when you're compiling code to a native platform.

Jeez. Talk about throwing stones in glass houses...

--benji