www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - the 3rd great war - D Vs C#

reply the Poor Novice One <the_member pathlink.com> writes:
Goodday Fellows!

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.
Jul 23 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
D compiles to host, and can thus avoid installation problems, and VM latencies
(and there *are* VM latencies, no matter
what the .NET advocates tell you)
D has very few libs, whereas .NET has a wealth of them.
D has proper templates. .NET does not
D can directly link to C functions. .NET must interface via P/Invoke
D has a reasonably responsive provider. Try getting your ideas adopted into .NET
D has very little exposure in the industry. .NET doesn't have this problem.
D has an overhead of about 60k (which is too much). .NET's overhead is measured
in megabytes (which, like Java, is a
joke).
D has std.recls. .NET doesn't (although there is a recls .NET mapping)
D has Walter Bright. .NET has Anders Hejlsberg.


"the Poor Novice One" <the_member pathlink.com> wrote in message
news:cdr2au$1u2u$1 digitaldaemon.com...

 Goodday Fellows!

 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.
Jul 23 2004
parent reply Gold Dragon <dragonwing dragonu.net> writes:
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?
Jul 24 2004
parent J C Calvarese <jcc7 cox.net> writes:
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/
Jul 24 2004
prev sibling next sibling parent pragma <EricAnderton at yahoo dot com> <pragma_member pathlink.com> writes:
In article <cdr2au$1u2u$1 digitaldaemon.com>, the Poor Novice One says...

Goodday Fellows!

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.


(If anyone feels that I'm off base with this, please feel free to critique my
statements. :) )




assembly manager, and JIT compiler.  These features have advantages in their own
right, but are an extravagance when writing small apps.  Furthermore, the .NET
runtime download is *huge* when downloaded via modem.  D provides a much more
friendly alternative as it has a much smaller development kit and requires no
runtime download at all for end-users of programs made using D.  This also means
that programs with D will experience any compatibility mishaps that an upgrade



run just great on any Win32 machine (NT4,95,98,Me,2000,XP) without the need for

NET, which leaves systems older Windows systems out of the picture.



require a change to the CLI, as that could disrupt other languages that rely
upon it as well.  D may continue to develop as DigitalMars sees fit, without
concerns of disrupting other products.  Furthermore, improvements to the D
specification are accomplished without the beuracracy of a standards body at
this time.

4) Simple and easy to use development kit that works well with existing tools.
NET has had a long bumpy road, requiring the development of new debugging and
development tools along the way.  This has hurt Microsoft and the development
community alike by requiring the purchase or creation of (not to mention
training for) these new programming tools.  D, on the other hand, works
perfectly fine with existing debuggers and IDE's.  Furthermore, D maintains
link-compatibility with C, so existing libraries may still be used with this new
language; .NET only maintains backwards compatibility via COM binaries and.

5) Vendor provided, cross platform capability and compatibility.  Granted, .GNU
and Mono have done an incredible job of bringing .NET to Linux and BSD.
However, these projects are 100% complete rewrites of Microsoft's
implementation.  D, on the other hand, is available for Windows as well as
Linux, thanks to sharing DigitalMars' D compiler front-end.  This means that
code written in D can be compiled and run on either platform with very little
effort.



performance losses when forced through the JIT compilation process, which also
causes more memory and disk bloat.  D relies on tried-and-true development tools
and techniques and requires relatively little to thrive on any given system. D
exists on multiple platforms (legacy and new alike) in an unhindered way, where


- Pragma
Jul 23 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:

2) D has fewer kitchen sinks (though it does seem to be getting more and
more)
3) D does arrays right
4) D wasn't born with a silver spoon in its mouth
5) D plays better with others

ps- My personal favorite Mr T quote: "Prediction? pain-n-n-n"

"the Poor Novice One" <the_member pathlink.com> wrote in message
news:cdr2au$1u2u$1 digitaldaemon.com...

 Goodday Fellows!

 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.





 Jul 23 2004



  parent reply "Phill" <phill pacific.net.au>  writes:


"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:cdr9mv$23ll$1 digitaldaemon.com...


 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.



 Jul 23 2004



 next sibling parent  "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


 What do you mean by a kitchen sink?


i think he's referring to "everything but the kitchen sink" i.e. extra cool
features.



 Jul 23 2004



prev sibling  parent reply Ben Hinkle <bhinkle4 juno.com>  writes:


Phill wrote:


 
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cdr9mv$23ll$1 digitaldaemon.com...


 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


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".



 Jul 23 2004



  parent  "Phill" <phill pacific.net.au>  writes:


"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...


 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




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.



 Jul 23 2004



prev sibling next sibling parent  Helmut Leitner <helmut.leitner wikiservice.at>  writes:


the Poor Novice One wrote:


 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.


(1) D is in the spirit of C: high performance and a small footprint 


(2) D is a community project: a Bright mind and an open community 


(3) D is built to last: Walter puts his livelong experience in to do it right.


(4) D is simple: it is built to be usable for everybody, even single programmers

    be happy to have a lot of experts for all of its 3000+ classes)

(5) D is consistent: you must be if you do with resources so restricted. 


-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com



 Jul 23 2004



prev sibling next sibling parent reply Deja Augustine <deja scratch-ware.net>  writes:


the Poor Novice One wrote:


 Goodday Fellows!

 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.


think we can all agree is for the best.



 Jul 23 2004



 next sibling parent  the Poor Novice <the_member pathlink.com>  writes:


In article <cdrvfr$2lmr$1 digitaldaemon.com>, Deja Augustine says...

the Poor Novice One wrote:


 Goodday Fellows!

 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.


think we can all agree is for the best.


Success and Happiness to you , mr.Deja !



 Jul 23 2004



prev sibling  parent reply J C Calvarese <jcc7 cox.net>  writes:


Deja Augustine wrote:

 the Poor Novice One wrote:
 

 Goodday Fellows!

 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.
 

 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/



 Jul 23 2004



  parent  Deja Augustine <deja scratch-ware.net>  writes:


J C Calvarese wrote:

 Deja Augustine wrote:
 

 the Poor Novice One wrote:


 Goodday Fellows!

 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.


 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.



 Jul 23 2004



prev sibling  parent reply Niko Korhonen <niktheblak hotmail.com>  writes:


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.


things are pretty much incompatible with each other, so I doubd that any 



godsend. Every value type is mapped to a struct that contains some 
necessary properties and methods appropriate for the type. The pinnacle 

to an object, one can call ToString() for /everything/. That allows the 
following syntax:





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.


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.


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.



 Aug 06 2004



  parent reply Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjuxNO SPAMyahoo.es>  writes:


Niko Korhonen wrote:







 

 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()); 


yes.





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.



 Aug 06 2004



  parent reply Niko Korhonen <niktheblak hotmail.com>  writes:


Juanjo Álvarez wrote:

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


Yes, this is a recently added feature in D and I like it. However, it's 

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:




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:










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




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 




 Aug 06 2004



  parent reply Nick <Nick_member pathlink.com>  writes:


In article <cf00i1$bov$1 digitaldaemon.com>, Niko Korhonen says...

A quick example:




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



 Aug 06 2004



 next sibling parent reply Lord Syl <Lord_member pathlink.com>  writes:


In article <cf088n$huv$1 digitaldaemon.com>, Nick says...

In article <cf00i1$bov$1 digitaldaemon.com>, Niko Korhonen says...

A quick example:




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




work, whereas D can, as it's compiled directly into machine code, with the
obvious speed advantage it implies.



 Aug 06 2004



 next sibling parent reply kinghajj <kinghajj_member pathlink.com>  writes:




work, whereas D can, as it's compiled directly into machine code, with the
obvious speed advantage it implies.



have they? Or Linux? They use that portability crap as marketing, when really


And, so what if D isn't interpreted? It's faster when it's compiled, and if D is
ever ported to other OSes, all you would have to do is recompile it on that new
system.



 Aug 06 2004



 next sibling parent  Berin Loritsch <bloritsch d-haven.org>  writes:


kinghajj wrote:




work, whereas D can, as it's compiled directly into machine code, with the
obvious speed advantage it implies.


 

 have they? Or Linux? They use that portability crap as marketing, when really



The marketing machine for MS never leaves MS systems.  What they claim
is the "big win" is that VB programmers can use and extend classes

is not necessarily cross-platform but cross-language.  I guess it is
how you define platform that matters. :/


 
 And, so what if D isn't interpreted? It's faster when it's compiled, and if D
is
 ever ported to other OSes, all you would have to do is recompile it on that new
 system.
 
 





 Aug 06 2004



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


In article <cf0c4t$ldl$1 digitaldaemon.com>, kinghajj says...


have they? Or Linux? They use that portability crap as marketing, when really



By the way, last I heard MS *was* working on .NET for Linux.  But the popular
consensus seems to be that it will be incomplete and inteded to allow folks to
use web services and such.  As for the Mac... that will probably be up to Apple
to take care of.


And, so what if D isn't interpreted? It's faster when it's compiled, and if D is
ever ported to other OSes, all you would have to do is recompile it on that new
system.


There are really only a few advantages to .NET.  The greatest advantage for MS
folks is that it replaces COM, MFC, and a host of other badly designed
technologies.  Beyond that its only real advantage over compiled code is that it
can be used for web services and the like, just like Java applets.  ie. stuff
can run quite easily in a sandbox.  But the CLI is on its way to standardization
so there's no reason that someone can't create a D/CLI compiler.  In fact it
looks like someone's already working on that :)


Sean



 Aug 06 2004



  parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


"Sean Kelly" <sean f4.ca> wrote in message
news:cf0k9v$pt8$1 digitaldaemon.com...

 In article <cf0c4t$ldl$1 digitaldaemon.com>, kinghajj says...


have they? Or Linux? They use that portability crap as marketing, when really



 By the way, last I heard MS *was* working on .NET for Linux.  But the popular
 consensus seems to be that it will be incomplete and inteded to allow folks to
 use web services and such.  As for the Mac... that will probably be up to Apple
 to take care of.


And, so what if D isn't interpreted? It's faster when it's compiled, and if D is
ever ported to other OSes, all you would have to do is recompile it on that new
system.


 There are really only a few advantages to .NET.  The greatest advantage for MS
 folks is that it replaces COM, MFC, and a host of other badly designed
 technologies.  Beyond that its only real advantage over compiled code is that
it
 can be used for web services and the like, just like Java applets.  ie. stuff
 can run quite easily in a sandbox.  But the CLI is on its way to
standardization
 so there's no reason that someone can't create a D/CLI compiler.  In fact it
 looks like someone's already working on that :)


Just out of interest, what're your criticisms of COM?



 Aug 07 2004



  parent  Sean Kelly <sean f4.ca>  writes:


In article <cf2f70$1pjs$1 digitaldaemon.com>, Matthew says...

Just out of interest, what're your criticisms of COM?


Frankly, I haven't used it enough to offer a truly informed answer.  COM has
just always seemed a terribly complex solution to the problems it was attempting
to solve.  I'll admit, however, that a lot of my complaints about MS APIs stem
from the fact that their use in C++ has always been a hundred times more
complicated than in any other supported language, and usually expects the use of
macros and such that really should not have been necessary (though I grant that
getting rid of them may have resulted in slower code).  .NET may have a more
complex back-end than MS' previous ideas, but its design is the cleanest they've
produced.


Sean



 Aug 07 2004



prev sibling next sibling parent  Berin Loritsch <bloritsch d-haven.org>  writes:


Lord Syl wrote:


 


 work, whereas D can, as it's compiled directly into machine code, with the
 obvious speed advantage it implies.



Actually, that's a misnomer.  The way the .NET stuff runs is that the
bytecode is delay-compiled.  IOW, it is fully compiled by the time the
user actually uses the code--but it is stored and distributed in a
platform neutral bytecode format.

Contrast this with Java hot spot which will compile hot spots based on
what is actually executed for a method.  That means that certain code
can actually get optimized out.  Same idea as above, but different
effect.



 Aug 06 2004



prev sibling next sibling parent reply Sean Kelly <sean f4.ca>  writes:


In article <cf0a88$k98$1 digitaldaemon.com>, Lord Syl says...



work, whereas D can, as it's compiled directly into machine code, with the
obvious speed advantage it implies.



as CLI bytecode until needed.  Herb Sutter has been writing some interesting
articles recently on the advantages and disadvantages of different execution
methods.  All in all .NET is one of the better things MS has ever done.


Sean



 Aug 06 2004



  parent  Andy Friesen <andy ikagames.com>  writes:


Sean Kelly wrote:


 In article <cf0a88$k98$1 digitaldaemon.com>, Lord Syl says...
 



work, whereas D can, as it's compiled directly into machine code, with the
obvious speed advantage it implies.


 
 

 as CLI bytecode until needed.  Herb Sutter has been writing some interesting
 articles recently on the advantages and disadvantages of different execution
 methods.  All in all .NET is one of the better things MS has ever done.


The really ironic thing is that a company with less influence could have 
never pulled it off.

Microsoft is abusing their monopoly to make software development better. :)

(and not just better on Windows, either.  Mono wouldn't have appeared if 
not for .NET.  Shame on you, Microsoft!!)

  -- andy



 Aug 06 2004



prev sibling  parent  Trejkaz Xaoza <trejkaz xaoza.net>  writes:


Lord Syl wrote:



 used for systems work, whereas D can, as it's compiled directly into
 machine code, with the obvious speed advantage it implies.


That's oversimplifying .NET a little too much.



Managed C++ also, etc.

CL (Common Language?) is somewhat "interpreted," but in the same way Java
bytecode is "interpreted."  That is to say, at some point, it ends up
running as native code.  This is a big contrast to true interpreted
languages such as shell scripts, where each line is interpreted every time
through.  (You can modify a shell script on the fly as long as you're
careful about it, and the changes will take effect immediately.)


code.  Just like there exist several compilers for compiling Java to 100%

certainty as people will gradually get paranoid about the performance
issues, just like they did with Java (and wrongly so.  GJC compiled Java
code ends up running slower than the JVM could run it.  It only starts up
much faster. :-))


as well as any D program could.

Likewise, there also seem to be efforts to make an interpreted, or a .NET
semi-interpreted version of D, so I'm not sure one can make a language
comparison based on differences in two specific runtime implementations.

TX

-- 
             Email: Trejkaz Xaoza <trejkaz xaoza.net>
          Web site: http://xaoza.net/trejkaz/
         Jabber ID: trejkaz jabber.xaoza.net
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73



 Aug 21 2004



prev sibling  parent  Berin Loritsch <bloritsch d-haven.org>  writes:


Nick wrote:


 In article <cf00i1$bov$1 digitaldaemon.com>, Niko Korhonen says...
 

A quick example:




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 ;-)


Even then, you never *really* know until you read the source code....



 Aug 06 2004