Hi all,

I wonder what you all think about the future of programming platforms. I've got a lot of code written in C# and lately I started to read more about D.

Honestly, I feel quite refreshed to re-discover native compilation in D again. It seems so much more lightweight than .NET framework or Java. Why there's so much push on the market (Microsoft, Sun) for executing source code within virtual machines? Do we really need yet another layer between hardware and our code? What's your opinion? I wonder how much stir up would D cause if it would have nice and powerful standardized library and really good IDE (like VS.NET)

lubosh escribió:
> Hi all,
> 
> I wonder what you all think about the future of programming platforms. I've got a lot of code written in C# and lately I started to read more about D.
> 
> Honestly, I feel quite refreshed to re-discover native compilation in D again.

Me too. :-)

It seems so much more lightweight than .NET framework or Java. Why there's so much push on the market (Microsoft, Sun) for executing source code within virtual machines? Do we really need yet another layer between hardware and our code? What's your opinion? I wonder how much stir up would D cause if it would have nice and powerful standardized library and really good IDE (like VS.NET)

I think the thought is: if in every machine there is a virtual machine with a 10Gb standard library, then, although it's slower than native code (but we're improving it each day!), writing software is much more easier and faster. Why? Because you already have most of the common functions and classes written for you: xml, streams, collections, network, etc. This also means that if your public method recieves a "List", because it's standard, everyone understands it quickly. Also the standard library can be improved, so each program improves as well.

Further, you have reflection, which gives you a tremendous power to extend your code with plugins (like in the Eclipse framework).

But... Everytime I open an app and it takes from one to two minutes I remember the good old native code, and that's I'd like D to become more popular. And I know the language itself isn't enough these days, and that a good standard library is a must (phobos and tango), as well as a really good IDE.

There isn't a "really good" IDE yet, but it's only a matter of time. Take a look at what the next release of Descent will have:

http://www.dsource.org/projects/descent/browser/trunk/descent.ui/screenshots/descent_ddbg.jpg?format=raw

Ary Manzana wrote:
> Why? Because you already have most of the common
> functions and classes written for you: xml, streams, collections,
> network, etc. This also means that if your public method recieves a
> "List", because it's standard, everyone understands it quickly. Also the
> standard library can be improved, so each program improves as well.

This point is actually only about standard libraries, not VMs.
As i see it, VMs actually are only about portability. Portability in
theory also means better (more individual) code optimzation.
VMs also make compilers a lot simpler. the difficult, platform dependent
part of code optimzation lies in the VM.

Java and C# have pretty fat runtime environments that give them a lot of
versatility and eat a lot of resources. But little of that is actually
dependent on the VM concept.
Reflection can be done natively, as well (also see FlectioneD).

Ary Manzana wrote:
> lubosh escribió:
>> Hi all,
>>
>> I wonder what you all think about the future of programming platforms. I've got a lot of code written in C# and lately I started to read more about D.
>>
>> Honestly, I feel quite refreshed to re-discover native compilation in D again.
> 
> Me too. :-)
> 
> It seems so much more lightweight than .NET framework or Java. Why there's so much push on the market (Microsoft, Sun) for executing source code within virtual machines? Do we really need yet another layer between hardware and our code? 

I think a big reason for .NET was the Itanium. It was going to make it possible to write x86 apps which would run without modification when we all switched to Itanium. We needed a virtual machine to isolate us from the thing which was likely to change (the CPU).

Java had a VM so it could run on SPARC (now dead), Alpha (now dead), Itanium (never really alive), PowerPC, and x86.

Instead, x86 asm now runs natively on the latest Macs.

Jascha Wetzel wrote:
> This point is actually only about standard libraries, not VMs.
> As i see it, VMs actually are only about portability. Portability in
> theory also means better (more individual) code optimzation.
> VMs also make compilers a lot simpler. the difficult, platform dependent
> part of code optimzation lies in the VM.

The thing is, you don't need a VM to get such portability. You need a language that doesn't have implementation defined or undefined behavior. It's *already* abstracted away from the target machine, why add another layer of abstraction?

I just don't get the reason for a VM. It seems like a solution looking for a problem.

As for the "makes building compilers easier", that is solved by defining an intermediate representation (don't need a VM), and building front ends to write to that intermediate representation, building separate optimizers and back ends to turn the intermediate representation into machine code. This is an old idea, and works fine (see gcc!).

Don Clugston wrote:
> Java had a VM so it could run on SPARC (now dead), Alpha (now dead), Itanium (never really alive), PowerPC, and x86.

Java originally was intended to be for embedded systems with very tight memory requirements, and having an interpreter is an easy way to squeeze more functionality into it. It's also hard to write a back end, so writing an interpreter instead is quicker and gets you to market faster.

Also, early Javas were interpreter only. JITs didn't come until much later, and the first one wasn't developed by Sun, it was developed by Symantec.

lubosh wrote:
> Hi all,
> 
> I wonder what you all think about the future of programming platforms. I've got a lot of code written in C# and lately I started to read more about D.
> 
> Honestly, I feel quite refreshed to re-discover native compilation in D again. It seems so much more lightweight than .NET framework or Java. Why there's so much push on the market (Microsoft, Sun) for executing source code within virtual machines? Do we really need yet another layer between hardware and our code? What's your opinion? I wonder how much stir up would D cause if it would have nice and powerful standardized library and really good IDE (like VS.NET)

Java runs on a VM largely because it allows proprietary applications to be run on any platform with a supporting VM.  The alternative would be to distribute code in source form and have the user build locally, or to pre-build for every target platform (which is not always feasible).  By contrast, the primary reason for .NET running in a VM is language interoperability (since .NET is a COM replacement).  I would say that a VM-based D would be useful in the same situations, though I don't have a need for this myself.


Sean

> It's *already* abstracted away from the target machine, why add another layer of abstraction?

to have a format for distribution that's still abstract but not human
readable. but i agree that VMs are rather obsolete.
one could as well ship intermediate code and finish compilation at first
start or installation. ideally one could consider optional processor
units like SSE in that last phase of compilation.
actually i think this or a multi-target binary format that allows for
alternate code units on function level would be a very effective
approach to these issues.
the later could be implemented by having the compiler generate several
versions of a function and let a detection unit decide at startup which
version to link.

Walter Bright wrote:
> Jascha Wetzel wrote:
>> This point is actually only about standard libraries, not VMs.
>> As i see it, VMs actually are only about portability. Portability in
>> theory also means better (more individual) code optimzation.
>> VMs also make compilers a lot simpler. the difficult, platform dependent
>> part of code optimzation lies in the VM.
> 
> The thing is, you don't need a VM to get such portability. You need a language that doesn't have implementation defined or undefined behavior. It's *already* abstracted away from the target machine, why add another layer of abstraction?
> 
> I just don't get the reason for a VM. It seems like a solution looking for a problem.
> 
> As for the "makes building compilers easier", that is solved by defining an intermediate representation (don't need a VM), and building front ends to write to that intermediate representation, building separate optimizers and back ends to turn the intermediate representation into machine code. This is an old idea, and works fine (see gcc!).

Op Mon, 30 Apr 2007 10:06:47 -0700
schreef Walter Bright <newshound1@digitalmars.com>:

> I just don't get the reason for a VM. It seems like a solution looking for a problem.
> 
> As for the "makes building compilers easier", that is solved by defining an intermediate representation (don't need a VM), and building front ends to write to that intermediate representation, building separate optimizers and back ends to turn the intermediate representation into machine code. This is an old idea, and works fine (see gcc!).

But what people call a "VM" is in fact an interpreter or a (JIT)
compiler for such an "intermediate representation"...   ;-)


And I think in the case of dynamic languages like Python, a JIT-compiler often can create much better code at run-time than a compiler could do when compiling it before run-time.


-- 
JanC

Jan Claeys wrote:
> 
> And I think in the case of dynamic languages like Python, a JIT-compiler
> often can create much better code at run-time than a compiler could do
> when compiling it before run-time.

One issue with run-time optimization is its impact on performance.  A traditional compiler can take as long as it wants to exhaustively optimize an application, while a JIT-compiler may only optimize in a way that does not hurt application responsiveness or performance.  At SDWest last year, there was a presentation on C++ vs. Java performance, and one of the most significant factors was that most Java JIT-compilers perform little if any optimization, while C++ compilers optimize exhaustively. That said, JIT optimization is still a relatively new practice, and with more cores being added to computers these days it's entirely possible that a JIT optimizer could run on one or more background CPUs and do much better than today.


Sean