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

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

(If anyone feels that I'm off base with this, please feel free to critique my statements. :) ) As much as I like C#, D has some very distinct advantages IMO. 1) Less baggage. C# relies on the .NET infrastructure: the .NET runtime, 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 to the .NET runtime might provide for C# apps. 2) Legacy Compatible. This goes hand-in-hand with point #1. D applications can run just great on any Win32 machine (NT4,95,98,Me,2000,XP) without the need for additional runtime support. C#, on the other hand, is only compatible with NET, which leaves systems older Windows systems out of the picture. 3) Unhindered specification. C# is tied down to the Common Language Infrastructure. It is unlikely that C# will adopt any improvements that would 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. To sum up: C# relies on .NET which is a massive juggernaut of a runtime that tries to be all things to all people. C# programs can be small, but experience 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 as C# does not. - Pragma
Jul 23 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
1) D is Rocky. C# is Mr T.
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!
 How does D surpass C# ? Any 5 best reasons, please?
 Please don't mention the DMD and Wiki comparisons of D with other

 just want to know the personal views of the this great community on this


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...
 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.
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...
 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".
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...
 1) D is Rocky. C# is Mr T.
 2) D has fewer kitchen sinks (though it does seem to be getting more



 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

 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

 C".

oic, thanks. Phill.
Jul 23 2004
prev sibling next sibling parent Helmut Leitner <helmut.leitner wikiservice.at> writes:
the Poor Novice One wrote:
 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.

(1) D is in the spirit of C: high performance and a small footprint (C# interface performance is bad, it isn't exactly small footprint) (2) D is a community project: a Bright mind and an open community (C# is proprietary, built to enhance market-grip) (3) D is built to last: Walter puts his livelong experience in to do it right. (C# .NET will not last, the update logic requires regular change of systems) (4) D is simple: it is built to be usable for everybody, even single programmers (C# .NET is a dinosaur like Java, built for larger project teams that will 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. (C# like Java can't be consistent, because hundreds of developers can't) -- 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!
 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.
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!
 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.

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!
 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/
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!
 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.
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.

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.
Aug 06 2004
parent reply Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjuxNO SPAMyahoo.es> writes:
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.
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 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.
Aug 06 2004
parent reply Nick <Nick_member pathlink.com> writes:
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
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:

# 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.
Aug 06 2004
next sibling parent reply kinghajj <kinghajj_member pathlink.com> writes:
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.

have they? Or Linux? They use that portability crap as marketing, when really almost everyone who uses .NET/C# are only worried about Windows developement. 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:

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.

Yeah, C# is interpreted, but yet I haven't seen Microsoft make .NET for Macs, have they? Or Linux? They use that portability crap as marketing, when really almost everyone who uses .NET/C# are only worried about Windows developement.

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 developed in C++, C#, F or some other .NET compatible language. So it 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...
Yeah, C# is interpreted, but yet I haven't seen Microsoft make .NET for Macs,
have they? Or Linux? They use that portability crap as marketing, when really
almost everyone who uses .NET/C# are only worried about Windows developement.

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...
Yeah, C# is interpreted, but yet I haven't seen Microsoft make .NET for Macs,
have they? Or Linux? They use that portability crap as marketing, when really
almost everyone who uses .NET/C# are only worried about Windows developement.

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:

 
 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.

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

C# isn't actually interpreted. It's just that .NET applications typically live 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...
 
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.

C# isn't actually interpreted. It's just that .NET applications typically live 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:
 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.

That's oversimplifying .NET a little too much. C# is not an interpreted language, because every implementation of it I can think of _compiles_ it into CL. VB.NET also compiles into CL. J# also, 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.) But nothing really says people couldn't make a C# compiler to 100% native code. Just like there exist several compilers for compiling Java to 100% native code, the existence of the very same for C# or CL is almost a 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. :-)) A C# program compiled to native code would work for system programming just 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:

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

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