Progress on implementing D on .NET.

http://www.reddit.com/r/programming/comments/7l5ce/hello_net_d_here_calling/

http://the-free-meme.blogspot.com/2008/12/hello-net-d-here-calling.html

Walter Bright Wrote:

>Progress on implementing D on .NET.<

- This sounds quite incredible :-)
- The more implementations of D there are, the more the language will have a chance to stick and become used, so I think this is a good thing, regardless what I say below.
- But is the dotnet able to support all things D supports? For example can you implement unions? Inline Asm code? How about the interface with compiled C code? Etc.
- One of the advantages of D, that is it produces true compiled executables, is lost here.
- I think performance on dotnet can be good enough for most programs, but a good C++-grade compiler like LLVM (LDC) can sometimes give even more running speed.
- D is supposed to be a system language, but I don't know if you can write system languages on dotnet, maybe not.
- C# is not that far from D, and it has several advantages (named arguments, better lambda, is much more widely used, more built-in reflection, LINQ, a way to support duck typing, run-time compilation of code, etc etc), so how can D compete with C#? While I can see how normal compiled D may compete with C# in some lower level niche, I don't see yet how D.net may compete with C#. What has D# to offer over C#? Maybe nothing?

Bye,
bearophile

There's also a risk: D has already unstable standard library (the division between the Phobos and Tango communities, with now just a common kernel). D# will have to use the libs of the dotnet, so it will use yet another standard lib. This will split in 3 parts the D community.

Bye,
bearophile

bearophile wrote:
> Walter Bright Wrote:
> 
>> Progress on implementing D on .NET.<
> 
> - This sounds quite incredible :-)

Cristi is an awesome and prolific developer. (He wrote the Zerobugs D debugger for Linux.)

> - The more implementations of D
> there are, the more the language will have a chance to stick and
> become used, so I think this is a good thing, regardless what I say
> below.

Yes.

> - But is the dotnet able to support all things D supports?

Yes. (!)

> For example can you implement unions?

Yes.

> Inline Asm code?

Yes (but it will be .net assembly code, not x86 assembly).

> How about the interface with compiled C code?

Yes.

> Etc. - One of the advantages of D,
> that is it produces true compiled executables, is lost here.

That's like saying that an advantage of D is that it can run under Windows, an advantage that is lost when one runs it under Linux. <g> D.Net expands the options, not shrinks them.

> - I think performance on dotnet can be good enough for most programs, but
> a good C++-grade compiler like LLVM (LDC) can sometimes give even
> more running speed.

Native D compilers aren't going away. There's no plan and no way D will become a .net-only language. All it is is expanding D's domain.

> - D is supposed to be a system language, but I
> don't know if you can write system languages on dotnet, maybe not.

You're right, but that doesn't matter. Use a D native compiler to do a system app. Use D.net to write an application that wants to interact with the .net ecosystem.

> - C# is not that far from D, and it has several advantages (named
> arguments, better lambda, is much more widely used, more built-in
> reflection, LINQ, a way to support duck typing, run-time compilation
> of code, etc etc), so how can D compete with C#? While I can see how
> normal compiled D may compete with C# in some lower level niche, I
> don't see yet how D.net may compete with C#. What has D# to offer
> over C#? Maybe nothing?

Advanced generative and metaprogramming capabilities for starters.

"bearophile" wrote
> - But is the dotnet able to support all things D supports? For example can you implement unions? Inline Asm code? How about the interface with compiled C code? Etc.

C++.net works just fine, and supports unions, etc.  Anything that C++ supports.  The difference is that you mark code that can be compiled into CLR and code that cannot. This provides a somewhat simple bridge between .NET and standard C functions.  Most likely, D.net would be the same way.

Asking if .net can support everything that D does is like asking if C can support everything that D does.  You can call C functions from D, even write D functions that are callable from C, but you don't write D code in C.

> - One of the advantages of D, that is it produces true compiled executables, is lost here.

> - I think performance on dotnet can be good enough for most programs, but a good C++-grade compiler like LLVM (LDC) can sometimes give even more running speed.

What is the advantage you see here?  Visual studio produces .exe files from my C# projects, which run just like normal executables.  They perform just as well as C++ programs as far as I can tell.  As far as I'm concerned, they *are* compiled executables.  Who cares if they are morphed into native binary code when I run them?

> - C# is not that far from D, and it has several advantages (named arguments, better lambda, is much more widely used, more built-in reflection, LINQ, a way to support duck typing, run-time compilation of code, etc etc), so how can D compete with C#? While I can see how normal compiled D may compete with C# in some lower level niche, I don't see yet how D.net may compete with C#. What has D# to offer over C#? Maybe nothing?

I think D's syntax is far superior to C# (save some C# features such as properties).  However, I do see issues with how to make D conform to .net without affecting the syntax benefits.  For example, how do you call .net functions with D arrays?  .net arrays are classes, whereas D arrays are structs.  If you have to use .net arrays instead of D arrays in order to use D.net, that would be a deal-killer for me.

-Steve

Hello Walter,

> Progress on implementing D on .NET.
> 
> http://www.reddit.com/r/programming/comments/7l5ce/hello_net_d_here_ca
> lling/
> 
> http://the-free-meme.blogspot.com/2008/12/hello-net-d-here-calling.htm
> l
> 


He mentioned this to me in an email recently when I was asking for help with zerobugs.

I think it is a great idea, and he's probably just the one to do it.  A few D members have made some attempts at .NET interfacing in the past, but I don't think any have attempted what he is doing.

At the least, it will be a good opportunity to put SafeD to good use. :)

If this works out, it might prove the feasability of a Mono project as well.

-JJR

Walter Bright:

>Yes (but it will be .net assembly code, not x86 assembly).<

I see, this is curious :-) And is inlining dotnet IL useful for something? :-)


>All it is is expanding D's domain.<

I understand the point, and you are right.


>Advanced generative and metaprogramming capabilities for starters.<

Uhmmmm... So far I don't see much advantages of using D# over C#. In C# you even have advanced (and recently easy enough to use too) ways to even generate code at run time. So I am not convinced yet.

More:

How can the dotnet GC support all the capabilities of D code? :-)

I think SafeD# can run pretty well on dotnet. It can even use the dotnet GC to its fullest, if SafeD# is well implemented.

Note that there are ways to translate dotnet IL to VM asm of the JavaVM, so later you may be able to run this D# on the JVM too.

-----------------------

Steven Schveighoffer:

>What is the advantage you see here?<

You don't need a huge VM to run them. I know lot of people don't care of this, so please ignore me.


>I think D's syntax is far superior to C#<

I have already listed several advantages of C# over D and more can be written. So I don't agree much.

Bye,
bearophile

"bearophile" wrote
> Steven Schveighoffer:
>
>>What is the advantage you see here?<
>
> You don't need a huge VM to run them. I know lot of people don't care of this, so please ignore me.

that is a good point.  But you are also right that I don't care :)  I already have to have .net for many other things so the space penalty is a wash anyways.

>>I think D's syntax is far superior to C#<
>
> I have already listed several advantages of C# over D and more can be written. So I don't agree much.

foreach in C# sucks compared to D
arrays in C# suck compared to D
no auto (at least in VS2005) (this is alleviated a lot by the Visual Studio
IDE though)
virtual functions require a 'virtual' marker.
overriding virtual functions requires an 'override' marker
delegates suck compared to D.

Basically, when I start working on C# programs after working on D programs, I find myself REALLY missing some of these syntaxes (esp. arrays).  Note that it's not that the features are *missing*, it's that *using* the features is not as nice.  Let's face it, all .net programs boil down to the same code anways, it's the syntax that makes the differences.

-Steve

This is very exciting!

.NET is the platform microsoft is pushing applications developers on, it will be very relevant for D if it can be used there. Loads of C++ developers seem to be migrating to C# too, I'm sure they will love D.NET.

Right now I'm trying to get into the programming business and C# is my best option. I was amazed to find out I could just program in C# without any learning. It's almost an exact subset of D, with many limitations and a bit more verbosity.

In addition to much better generic and metaprogramming, there are lots of more modest things I missed in C# too. It's type inference is inferior for example, and lack of free functions very annoying. Also nothing as clean as scope statements.

C# on the other hand has reflection, properties and Linq, which is just awesome. I noticed many developers really adore properties, perhaps it's worth some attention to rethink how this is handled in D. It is used everywhere in .NET.

The fact that C# and D are so similar will only help C# programmers migrating to D.NET ;)

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:gip4o7$1pqj$1@digitalmars.com...
>>Advanced generative and metaprogramming capabilities for starters.<
>
> Uhmmmm... So far I don't see much advantages of using D# over C#. In C# you even have advanced (and recently easy enough to use too) ways to even generate code at run time. So I am not convinced yet.
>

T foo(T)(T a, T b, T c)
{
    return (a * b) + c;
}

Try doing that in C#.