"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:cdsgjs$3u5$1@digitaldaemon.com...
> Phill wrote:
>
> >
> > "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:cdr9mv$23ll$1@digitaldaemon.com...
> >> 1) D is Rocky. C# is Mr T.
> >> 2) D has fewer kitchen sinks (though it does seem to be getting more
and
> >> more)
> >
> > What do you mean by a kitchen sink?
> >
> > Phill.
>
> http://www.goenglish.com/EverythingButTheKitchenSink.asp
>
> I was thinking more about .Net than C# since language-wise D and C# have
the
> roughly the same features and it just many small things that become the difference. I would count C++ as something that has "lost the simplicity
of
> C".

oic, thanks.

Phill.

Deja Augustine wrote:
> the Poor Novice One wrote:
> 
>> Goodday Fellows!
>> How does D surpass C# ? Any 5 best reasons, please?
>> Please don't mention the DMD and Wiki comparisons of D with other languages.I
>> just want to know the personal views of the this great community on this topic.
>>
>>
> 
> I would simply like to add that if the code gods smile upon me, D will soon be able to interop with .NET while still maintaining it's current compatibility with C-linked binaries.
> 
> D.NET is turning out to be much closer to Managed D than D# which I think we can all agree is for the best.

Sounds like fun. Would it have access to the many, many .NET libraries out there?

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

J C Calvarese wrote:
> Deja Augustine wrote:
> 
>> the Poor Novice One wrote:
>>
>>> Goodday Fellows!
>>> How does D surpass C# ? Any 5 best reasons, please?
>>> Please don't mention the DMD and Wiki comparisons of D with other languages.I
>>> just want to know the personal views of the this great community on this topic.
>>>
>>>
>>
>> I would simply like to add that if the code gods smile upon me, D will soon be able to interop with .NET while still maintaining it's current compatibility with C-linked binaries.
>>
>> D.NET is turning out to be much closer to Managed D than D# which I think we can all agree is for the best.
> 
> 
> Sounds like fun. Would it have access to the many, many .NET libraries out there?
> 

Of course.

Matthew wrote:
> D has an overhead of about 60k (which is too much). .NET's overhead is measured in megabytes (which, like Java, is a
> joke).

I don't know about compilers (how to make them but I do know how they work overall) but what is this overhead of 60k? Does C++ compilers do that too or is the 60k from the Garbage Collector?

Gold Dragon wrote:
> Matthew wrote:
> 
>> D has an overhead of about 60k (which is too much). .NET's overhead is measured in megabytes (which, like Java, is a
>> joke).
> 
> 
> I don't know about compilers (how to make them but I do know how they work overall) but what is this overhead of 60k? Does C++ compilers do that too or is the 60k from the Garbage Collector?

It's more the garbage collector than anything else. In C++, there's no garbage collection. In the long run (i.e. larger and more complex programs), D programs should be smaller than equivalent C++ programs.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

This is a little late reply for this thread (does anyone even read the old topics?), but I've decided to share my experiences with these languages.

There are some very nice things in C# and in D. Unfortunately these nice things are pretty much incompatible with each other, so I doubd that any of the C# niceties can be integrated with D.

Let's start with C#. The automatic boxing/unboxing of value types is a godsend. Every value type is mapped to a struct that contains some necessary properties and methods appropriate for the type. The pinnacle of this technique is IMO string formatting; since every type in C# maps to an object, one can call ToString() for /everything/. That allows the following syntax:

# int x = 4;
# MyObject obj = new MyObject();
# Console.WriteLine("{0}: {1}", x.ToString(), obj.ToString());

This is by far the nicest string formatting syntax in the C family of languages that I've ever seen. By a large margin. In fact, that kind of formatting syntax is only possible because of automatic boxing. It also makes template programming easier since everything is guaranteed to be a System.Object, really.

I also like how the value types are logically mapped into the equivalent structs. Important things like maximum value and such are intuitively mapped into Int32.MaxValue and such. D's view on this one (int.sizeof and such) seems a bit hackish. It /seems/ that there is a struct "int" or "Int32" somewhere in D containing the sizes and maximum values, but there isn't. NET's view on this one is simply more OOP, logical and intuitive, IMO.

C# also forces you to use the override/new keywords and it requires you to use ref and out specifiers also in a method call, and not just method definition. I certainly like that a lot. It makes the code much nicer to read. I would love to have that in D.

My only real grudge with C# is the way arrays are handled, especially since D showed the world how arrays *should* be handled. It's the plain old non-resizable, second-class citizen view. No slices or anything like that. Array.Equals() only checks for address and not contents (as well as operator== for arrays), and Array.GetHashCode() generates the hash code based on the address instead of the contents. Since you can't overload Equals() or operator== for arrays, you have to write a comparison function to check whether array contents are identical. It's trivial work, but it's not /fun/ as in D.

Also when overloading operator== for user-specified types, you have to hackishly check for null since == can't be used for that anymore. I do it as !(x is object) since that can only fail if x is null. It's still not as nice as it could be.

D has explicit operators for comparing the contents (==) and address (===). That is indeed very nice.

Niko Korhonen wrote:

> # int x = 4;
> # MyObject obj = new MyObject();
> # Console.WriteLine("{0}: {1}", x.ToString(), obj.ToString());

> This is by far the nicest string formatting syntax in the C family of languages that I've ever seen.

writefln(toString(x), ": ", obj.toString());

And you don't need the {0} and {1} But I like C# autoboxing (in general),
yes.

> C# also forces you to use the override/new keywords

This is one of the things I (and a lot of other people, it seems) would
really like to see included in 1.0 (not after).

> and it requires you
> to use ref and out specifiers also in a method call
> and not just method
> definition.

I would like to see "in" parameter specification enforced (producing a compile error if you try to change an in parameter) but I don't see the point in forcing the calls to use in/out/inout.

Juanjo Álvarez wrote:
> writefln(toString(x), ": ", obj.toString()); 

Yes, this is a recently added feature in D and I like it. However, it's still not as general as in C#, you can't call x.toString() for /any/ type in D. But it does remain as a minor nuance.

> I would like to see "in" parameter specification enforced (producing a
> compile error if you try to change an in parameter) but I don't see the
> point in forcing the calls to use in/out/inout.

A quick example:

# int x = 5;
# func(x);

Does func() change the value of x? You can't be sure. It's very unlikely, since POD types are passed by value and not reference. A programmer with a C or Java background will think it's very unlikely that x will change. But when it *does* change (the function was declared as void func(out int x)), you're in for a mighty surprise.

In C it is:

# int x;
# ...
# func(&x);

It's rather obvious that func changes the value of x. In C#:

# int x = 5;
# MyClass.Func(out x);

It's also obvious that x will change. But in C++/D:

# int x = 5;
# func(x);

You have no idea whether x will be changed without looking at the function declaration/definition. Not that this wouldn't be ridiculously easy in Visual Studio or any good IDE, though.

This is also a minor nuance, but it still IMHO tips the scale in favour of C# by a very little amount.

In article <cf00i1$bov$1@digitaldaemon.com>, Niko Korhonen says...
>
>A quick example:
>
># int x = 5;
># func(x);
>
>Does func() change the value of x? You can't be sure. It's very unlikely, since POD types are passed by value and not reference. A programmer with a C or Java background will think it's very unlikely that x will change. But when it *does* change (the function was declared as void func(out int x)), you're in for a mighty surprise.

I think it should be safe to assume that the programmer knows the definition of the function he/she is calling. When giving pointers in C you also "never know" whether the function is just reading the data (can't pass strings or large data structures without using pointers) or if it's altering it. Unless you actually RTFM ;-)

Nick

In article <cf088n$huv$1@digitaldaemon.com>, Nick says...
>
>In article <cf00i1$bov$1@digitaldaemon.com>, Niko Korhonen says...
>>
>>A quick example:
>>
>># int x = 5;
>># func(x);
>>
>>Does func() change the value of x? You can't be sure. It's very unlikely, since POD types are passed by value and not reference. A programmer with a C or Java background will think it's very unlikely that x will change. But when it *does* change (the function was declared as void func(out int x)), you're in for a mighty surprise.
>
>I think it should be safe to assume that the programmer knows the definition of the function he/she is calling. When giving pointers in C you also "never know" whether the function is just reading the data (can't pass strings or large data structures without using pointers) or if it's altering it. Unless you actually RTFM ;-)
>
>Nick
>
>

Another reason that has not been stated is that C# is a interpreted language, which can be more portable than D, but due to it, C# can't be used for systems work, whereas D can, as it's compiled directly into machine code, with the obvious speed advantage it implies.