www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs. C#

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
I want to write an article about D. Therefore I want to show more
details and advantages of D compared to C++, Java and C#. But I never
used C#.

What are concrete things that are better in D or C#? Can you make examples?
Nov 23 2006
next sibling parent reply "Andrey Khropov" <andkhropov_nosp m_mtu-net.ru> writes:
Frank Benoit (keinfarbton) wrote:

 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.
 
 What are concrete things that are better in D or C#? Can you make examples?

I think the biggest thing is that you have no metaprogramming support in C# (only type-parametrized classes and functions via generics) whereas you have templates in D. Plus DbC and built-in unit testing. Another good thing C# lacks is aliases (AFAIK only namespace aliases are supported) and strong typedefs. Anyway there's a comparison page http://www.digitalmars.com/d/comparison.html -- AKhropov
Nov 23 2006
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Andrey Khropov schrieb:
 I think the biggest thing is that you have no metaprogramming support in C#
 (only type-parametrized classes and functions via generics) whereas you have
 templates in D.
 
 Plus DbC and built-in unit testing.
 
 Another good thing C# lacks is aliases (AFAIK only namespace aliases are
 supported) and strong typedefs.
 
 Anyway there's a comparison page http://www.digitalmars.com/d/comparison.html
 

Thanks for your reply. I am aware of the comparison table on digitalmars.com. But I am very interested in more detailed points of view, because a simple YES/NO is not really sufficient for an article. So, if you know C# or even C# 3.0 I appreciate to hear about your experience and opinions. With these I can go to mr. google and do a more specific and deeper investigation. Your listed points are a good start for me, thanks again.
Nov 23 2006
prev sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Andrey Khropov wrote:
 Frank Benoit (keinfarbton) wrote:
 
 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.

 What are concrete things that are better in D or C#? Can you make examples?

I think the biggest thing is that you have no metaprogramming support in C# (only type-parametrized classes and functions via generics) whereas you have templates in D. Plus DbC and built-in unit testing. Another good thing C# lacks is aliases (AFAIK only namespace aliases are supported) and strong typedefs. Anyway there's a comparison page http://www.digitalmars.com/d/comparison.html

Aliases are supported on C# 2.0 although a lot more limited than in D. // Alias a namespace using Utilities = System.Collections; // Alias a class. using List = System.Collections.ArrayList; // Alias an instance of a generic class. using IntegerList = System.Collections.Generic.List<int>; That's about all you can make an alias for on C#.
Nov 23 2006
prev sibling next sibling parent reply antonio <antonio abrevia.net> writes:
Frank Benoit (keinfarbton) wrote:
 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.
 
 What are concrete things that are better in D or C#? Can you make examples?

best on c# framework documentation debugger Microsoft Integrated Developement Environment (IDE :-) ) Very good "guides" for framework extensibility (ex: connection with a different SGBD are very standardized...you can find really good implementations of ado.net for PostgreSQL, Firebird. D Database access is ridiculous... because D has not a proposal for standard database connectivity ) D: *has not an standard framework (has not the "rules" for a standard framework extensibility) *documentation: if you are not talking about D compiler, you have not really "massive" framework/libraries/extensions to document... and the ones you have are poorly documented (forums are the main "documentation" repository) *not native debugger. *Poor IDEs(syntax highlight and so on... nothing really ). D weakness... is just the things you need to be productive: No one want's to work in a unique framework... in a unique "path"... in a required D-Fundation: D people is more worried about Linux vs Windows than D productivity.
Nov 23 2006
next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Antonio,
the points you listed are very good. Well "good" because I know nothing
about C#, and this is also true for the things around C# and Dot NET.
First time I hear about those "rules".

What do you think if you put the focus on the languages itself? Ignoring
existing libs, IDEs ...
Nov 23 2006
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Frank Benoit (keinfarbton) escribió:
 Antonio,
 the points you listed are very good. Well "good" because I know nothing
 about C#, and this is also true for the things around C# and Dot NET.
 First time I hear about those "rules".
 
 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...

I think this days a language isn't just "the language", i.e.: the syntaxis and semantic. Questions I want to ask to a language: 1. Does it have a great power of expresiveness? 2. Will I have to program all the *so common* classes like collections, io, network, etc., or instead of focusing on my problem I'll have to invent the wheel again? 3. Will I get my job done quickly? 4. Will my programs require some other annoying frameworks, virtual machines and on on the target machine? 5. Will my programs be fast? My answers would be: 1. Yes, and I think it beats C#, although reflection is widely used nowadays, and D dosen't have this (I don't know if this is possible for a compiled-to-native language). 2. Well, you'll surely find some good libraries out there. But integration with other systems that use some other libraries will be very painful. And choosing a library is also some time you'll loose. If interfaces (like the ones in java.util) are defined in D, together with a good core library, everything should be easier to do. But I think interfaces are not that efficient in D... am I wrong? And yes, you'll feel that poor performance in your 2Ghz double core processor. 3. Not as quick as programming in C# or Java, because you don't have powerful IDEs, and point 2 is also a thing to consider. 4. No, and it's one of the things I like most of D: a great power of expressiveness compiled to native binaries. 5. Yes, very fast, and that's another point for D. But, as far as I know, speed is not (that much) a concern, and everybody has a virtual machine, so...
Nov 23 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Ary Manzana wrote:
 Frank Benoit (keinfarbton) escribió:
 Antonio,
 the points you listed are very good. Well "good" because I know nothing
 about C#, and this is also true for the things around C# and Dot NET.
 First time I hear about those "rules".

 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...

I think this days a language isn't just "the language", i.e.: the syntaxis and semantic. Questions I want to ask to a language: 1. Does it have a great power of expresiveness? 2. Will I have to program all the *so common* classes like collections, io, network, etc., or instead of focusing on my problem I'll have to invent the wheel again? 3. Will I get my job done quickly? 4. Will my programs require some other annoying frameworks, virtual machines and on on the target machine? 5. Will my programs be fast?

6. Will my programs be portable?
 
 My answers would be:
 1. Yes, and I think it beats C#, although reflection is widely used 
 nowadays, and D dosen't have this (I don't know if this is possible for 
 a compiled-to-native language).
 2. Well, you'll surely find some good libraries out there. But 
 integration with other systems that use some other libraries will be 
 very painful. And choosing a library is also some time you'll loose. If 
 interfaces (like the ones in java.util) are defined in D, together with 
 a good core library, everything should be easier to do. But I think 
 interfaces are not that efficient in D... am I wrong? And yes, you'll 
 feel that poor performance in your 2Ghz double core processor.
 3. Not as quick as programming in C# or Java, because you don't have 
 powerful IDEs, and point 2 is also a thing to consider.
 4. No, and it's one of the things I like most of D: a great power of 
 expressiveness compiled to native binaries.

Amen to that. Java, C#, python etc may have great libraries, but you basically have to install the whole dang library collection on any machine that you intend to run your program on. "Hey I've got this great little 10 line script"... kind of loses its cool factor when you have to install 50MB or more of other stuff just to use the script.
 5. Yes, very fast, and that's another point for D.
 
 But, as far as I know, speed is not (that much) a concern, and everybody 
 has a virtual machine, so...

6. D code is fairly portable between Windows/Linux/Mac, so with care, and judicious selection of external libraries, a recompile for the target machine is all that is needed. Java has an embedded version. D lacks any sort of embedded strategy right now, AFAIK. Though it should be great for embedded stuff. --bb
Nov 23 2006
parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Bill Baxter wrote:
...
 
 
 6.  D code is fairly portable between Windows/Linux/Mac, so with care, 
 and judicious selection of external libraries, a recompile for the 
 target machine is all that is needed.   Java has an embedded version.  D 
 lacks any sort of embedded strategy right now, AFAIK.  Though it should 
 be great for embedded stuff.
 
 
 --bb

Yeah, the embedded support is kinda weak. I made that linux -> arm-wince-pe cross compiler, which has quirks and is getting old :( This would be much better if we could just have one person working on each of the platforms out there that need to be targetted. I'm thinking arm-linux, arm-symbian (if possible), and arm-palmos (if we care). These should all be reachable through gdc. Not sure what other embedded OSes are out there that are not too proprietary or hard to hit. Anyhow, I think good embedded support is doable, we just need a couple folks actually willing to do it.
Nov 23 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
Ary Manzana wrote:
 Frank Benoit (keinfarbton) escribió:
 Antonio,
 the points you listed are very good. Well "good" because I know nothing
 about C#, and this is also true for the things around C# and Dot NET.
 First time I hear about those "rules".

 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...

I think this days a language isn't just "the language", i.e.: the syntaxis and semantic. Questions I want to ask to a language: 1. Does it have a great power of expresiveness? 2. Will I have to program all the *so common* classes like collections, io, network, etc., or instead of focusing on my problem I'll have to invent the wheel again? 3. Will I get my job done quickly? 4. Will my programs require some other annoying frameworks, virtual machines and on on the target machine? 5. Will my programs be fast? My answers would be: 1. Yes, and I think it beats C#, although reflection is widely used nowadays, and D dosen't have this (I don't know if this is possible for a compiled-to-native language). 2. Well, you'll surely find some good libraries out there. But integration with other systems that use some other libraries will be very painful. And choosing a library is also some time you'll loose. If interfaces (like the ones in java.util) are defined in D, together with a good core library, everything should be easier to do. But I think interfaces are not that efficient in D... am I wrong? And yes, you'll feel that poor performance in your 2Ghz double core processor.

I don't think D interfaces would have any less performance potential than any other language using interfaces (or even C++ MI)? The one big advantage for D is that the methods would already be compiled, so when you 'traverse' an object hierarchy the JIT wouldn't need to be (re)run for each method.
 3. Not as quick as programming in C# or Java, because you don't have 
 powerful IDEs, and point 2 is also a thing to consider.
 4. No, and it's one of the things I like most of D: a great power of 
 expressiveness compiled to native binaries.
 5. Yes, very fast, and that's another point for D.
 
 But, as far as I know, speed is not (that much) a concern, and everybody 
 has a virtual machine, so...

I agree except for this last point - C and C++ are still so popular in large part because of performance. D needs to at least meet C/++ and exceed Java and C# for it to succeed.
Nov 23 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Dave wrote:
 I don't think D interfaces would have any less performance potential 
 than any other language using interfaces (or even C++ MI)?

Since D interfaces are implemented just like C++ MI, there is no performance difference between the two.
Nov 24 2006
parent reply Ary Manzana <ary esperanto.org.ar> writes:
Walter Bright escribió:
 Dave wrote:
 I don't think D interfaces would have any less performance potential 
 than any other language using interfaces (or even C++ MI)?

Since D interfaces are implemented just like C++ MI, there is no performance difference between the two.

I wrote that because of the recent discusion about iterators. I copy and paste: Bill Baxter said:
 That's like C++'s way.  Iterator is basically a generalized pointer.
 The other proposal is more like Java/Python/C#'s way, where the
 iterator  is like a pointer that knows it's own limits.

Walter Bright said:
 I think the C++ like way will be a lot more efficient, and I think it
 will work.

So now I wonder what "a lot more efficient" means. Some people (like me) think it's very hard to understand C++ iterator semantic, and it's also harder to implement your own iterator. And if doing it that way dosen't improve your performance, then you are loosing easy development against a little better performance (which you can always have by not using iterators at all).
Nov 24 2006
parent Dave <Dave_member pathlink.com> writes:
Ary Manzana wrote:
 Walter Bright escribió:
 Dave wrote:
 I don't think D interfaces would have any less performance potential 
 than any other language using interfaces (or even C++ MI)?

Since D interfaces are implemented just like C++ MI, there is no performance difference between the two.

I wrote that because of the recent discusion about iterators. I copy and paste: Bill Baxter said: > That's like C++'s way. Iterator is basically a generalized pointer. > The other proposal is more like Java/Python/C#'s way, where the > iterator is like a pointer that knows it's own limits. Walter Bright said: > I think the C++ like way will be a lot more efficient, and I think it > will work. So now I wonder what "a lot more efficient" means. Some people (like me) think it's very hard to understand C++ iterator semantic, and it's also harder to implement your own iterator. And if doing it that way dosen't improve your performance, then you are loosing easy development against a little better performance (which you can always have by not using iterators at all).

Ah, I think I see your concerns with interfaces and iterators. From what was discussed, I don't think something like C#'s IEnumerable interface would be needed. Generic UDT templates could be built with something like C#'s GetEnumerator, MoveNext, Reset and Current w/o using IEnumerable (these would be 'built-in'). Then they could be used via the standard foreach syntax with implicit type inference, and avoid the overhead of the interface. I think what Walter has in mind would be the best of both worlds really.
Nov 24 2006
prev sibling parent Serg Kovrov <kovrov no.spam> writes:
Hi Ary Manzana, you wrote:
 I think this days a language isn't just "the language", i.e.: the 
 syntaxis and semantic.
 
 Questions I want to ask to a language:
 1. Does it have a great power of expresiveness?
 2. Will I have to program all the *so common* classes like collections, 
 io, network, etc., or instead of focusing on my problem I'll have to 
 invent the wheel again?
 3. Will I get my job done quickly?
 4. Will my programs require some other annoying frameworks, virtual 
 machines and on on the target machine?
 5. Will my programs be fast?

Excellent points, Ary. I would also add: 6. Will my program use memory efficiently? -- serg.
Nov 24 2006
prev sibling parent reply antonio <antonio abrevia.net> writes:
Frank Benoit (keinfarbton) wrote:
 Antonio,
 the points you listed are very good. Well "good" because I know nothing
 about C#, and this is also true for the things around C# and Dot NET.
 First time I hear about those "rules".
 
 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...
 
 
 

In the posts exposed in last 3 days, you can see a lot of comparisons and opinions. Here you are my basic opinion: It's an error to take C# in an isolated way: if you do this, D is more featured language compiler. C# must be analyzed as part of .Net platform (Virtual Machine, Framework, Compiler), because c# was thought as the "way" programmers access to and extends framework. C# is "interface" oriented because framework standarization: from this point of view, there is a lot of functionalities proposed in D that are not really utile: Microsoft was to try how to... and Java gived him the way. Of course, some people disagree some interfaces proposals, but it's the cost of productivity. My conclusion: D is not "productivity" oriented (Walter and D people wants to have the best multipurpose "full-possibilities" compiler) and C# is only the .Net platform productive language: You can't compare them, because they are not the same (you can compare D, C and C++, you can compare C# and Java... but you CAN'T compare D with C# or Java... ). My error: I lived in a mistake the last 3 years: I spected D people to work/produce a complete platform (because the fashioned way: .Net, Mono, wxWindows, PHP,...). My error was a simple confusion: D is a language, not a platform. D community never will implement this "platform/framework" because they are interested in a practical exploration of possibilities not really in a serious productive alternative... this is work for other people... D is only the tool. See you Antonio
Nov 25 2006
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Antonio,

Even at Microsoft, I would hazard the guess that different people 
implemented the .NET Framework classes than actually developed the CLR, 
or even VB.NET, C#, J#, etc.  Each probably even had its own project 
manager, but that's really a guess.

Microsoft has the resources to put into this, but D doesn't have it all 
yet.  If you are comparing infrastructures, D will not win against C#. 
It is true that it is not ready for that fight yet.

That said, comparing it to C/C++ is a much easier win for much the same 
reasons.

Some programmers do not need the full class library written for them, 
though.  If I need to parse xml, I'll either use a C library or write my 
own (which I have done.)  You're very correct that D is not a RAD 
language, and I don't think it's intended to be one.

Over time, different class or library frameworks will emerge for D, and 
one will become popular.  Since this has not yet happened, most people 
are not interested in the obvious comparison you've made - rather, in 
the comparison for the future.

To say that my pile of $1,000,000 in cash is better than your $600,000 
in investment - right now - is easy.  But it's much more interesting to 
know if the investment will be worth more in ten years or not.  I think 
that is the question being asked.

Just my opinion.

Also, I disagree with your comments on C#; I don't believe it was 
designed as the way to access the framework.  In fact, I think .NET 
smells much stronger of Visual Basic .NET than of C#.  But that's really 
an opinion.

Further, C#'s syntax and features are actually represented in a standard 
which would theoretically be framework agnostic, much like JavaScript. 
AFAIK.

-[Unknown]


 My conclusion:
 
 D is not "productivity" oriented (Walter and D people wants to have the 
 best multipurpose "full-possibilities" compiler) and C# is only the .Net 
 platform productive language:  You can't compare them, because they are 
 not the same  (you can compare D, C and C++, you can compare C# and 
 Java... but you CAN'T compare D with C# or Java... ).
 
 My error:
 
 I lived in a mistake the last 3 years:  I spected D people to 
 work/produce a complete platform (because the fashioned way:  .Net, 
 Mono, wxWindows, PHP,...).
 
 My error was a simple confusion:  D is a language, not a platform.
 
 D community never will implement this "platform/framework" because they 
 are interested in a practical exploration of possibilities not really in 
 a serious productive alternative... this is work for other people... D 
 is only the tool.
 
 See you
 Antonio

Nov 25 2006
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Unknown W. Brackets wrote:

 Also, I disagree with your comments on C#; I don't believe it was 
 designed as the way to access the framework.  In fact, I think .NET 
 smells much stronger of Visual Basic .NET than of C#.  But that's really 
 an opinion.

And the smell of "NotJava .NET" is pretty strong too. --bb
Nov 25 2006
parent reply Dave <Dave_member pathlink.com> writes:
Bill Baxter wrote:
 Unknown W. Brackets wrote:
 
 Also, I disagree with your comments on C#; I don't believe it was 
 designed as the way to access the framework.  In fact, I think .NET 
 smells much stronger of Visual Basic .NET than of C#.  But that's 
 really an opinion.

And the smell of "NotJava .NET" is pretty strong too. --bb

Funny thing is, I think that most of the runtime and big chunks of the .NET library can trace their roots back to MS Visual J++ <g> Was .NET announced before or after Sun won the judgement? (I can't remember). It may turn out that MS lost the battle but won the war on that one, if losing Java was the impetus for .NET anyhow.
Nov 25 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Dave wrote:
 Bill Baxter wrote:
 Unknown W. Brackets wrote:

 Also, I disagree with your comments on C#; I don't believe it was 
 designed as the way to access the framework.  In fact, I think .NET 
 smells much stronger of Visual Basic .NET than of C#.  But that's 
 really an opinion.

And the smell of "NotJava .NET" is pretty strong too. --bb

Funny thing is, I think that most of the runtime and big chunks of the .NET library can trace their roots back to MS Visual J++ <g> Was .NET announced before or after Sun won the judgement? (I can't remember). It may turn out that MS lost the battle but won the war on that one, if losing Java was the impetus for .NET anyhow.

It was definitely round about the same time Sun was suing them over their non-standard extensions to Java. I think folks at Microsoft liked Java the language, but if Sun wasn't going to let them add COM extensions and win32 APIs and such, then it was never going to be a viable replacement for VB. So they did what they had to do in my view. C# .NET seems to be a pretty sweet thing for anyone willing to swallow the Microsoft Kool-aid. --bb
Nov 26 2006
parent "JohnC" <johnch_atms hotmail.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:ekd9kg$1e89$1 digitaldaemon.com...
 Dave wrote:
 Bill Baxter wrote:
 Unknown W. Brackets wrote:

 Also, I disagree with your comments on C#; I don't believe it was 
 designed as the way to access the framework.  In fact, I think .NET 
 smells much stronger of Visual Basic .NET than of C#.  But that's 
 really an opinion.

And the smell of "NotJava .NET" is pretty strong too. --bb

Funny thing is, I think that most of the runtime and big chunks of the .NET library can trace their roots back to MS Visual J++ <g> Was .NET announced before or after Sun won the judgement? (I can't remember). It may turn out that MS lost the battle but won the war on that one, if losing Java was the impetus for .NET anyhow.

It was definitely round about the same time Sun was suing them over their non-standard extensions to Java. I think folks at Microsoft liked Java the language, but if Sun wasn't going to let them add COM extensions and win32 APIs and such, then it was never going to be a viable replacement for VB. So they did what they had to do in my view. C# .NET seems to be a pretty sweet thing for anyone willing to swallow the Microsoft Kool-aid. --bb

Almost right. It was really the virtual machine that Microsoft was interested in. The JVM team felt increasingly stifled by Sun, and wanted to take the VM places it couldn't go (whether for legal or other reasons). Ambitions for multiple-language support, plus deeper interoperation with COM and native code, motivated them to join forces with the existing COM team. COM 2.0 was born ... but it was a brief marriage. Apparently they fell out over how they should implement memory management. One half wanted to continue with explicit management (reference counting via AddRef/Release) while the other was interested in garbage collection. So they parted company. Soon, the GC guys gave birth to the CLR (acquiring a company who'd developed a research VM along the way). Meanwhile, the C++ team was investigating meta data. With the new CLR team, they developed Microsoft Intermediate Language, and soon had a prototype GC and runtime. All they needed now was a language. C# started life in the late nineties as the weird offspring of C++ and IDL. It was codenamed "Cool" (C-based Object Oriented Language). C# was announced in mid-2000 along with .NET (which grew out of ASP+), and the first public release followed in 2002. Now, where'd I put that bottle of Kool Aid?
Nov 26 2006
prev sibling parent Antonio <antonio abrevia.net> writes:
Unknown W. Brackets escribió:
 Antonio,
 
 Even at Microsoft, I would hazard the guess that different people 
 implemented the .NET Framework classes than actually developed the CLR, 
 or even VB.NET, C#, J#, etc.  Each probably even had its own project 
 manager, but that's really a guess.
 
 Microsoft has the resources to put into this, but D doesn't have it all 
 yet.  If you are comparing infrastructures, D will not win against C#. 
 It is true that it is not ready for that fight yet.

Otherwise, people is producing heterogeneous small solutions: Some "guided" work (a "unique" guided work) must be interesting in a common library production.
 
 That said, comparing it to C/C++ is a much easier win for much the same 
 reasons.
 
 Some programmers do not need the full class library written for them, 
 though.  If I need to parse xml, I'll either use a C library or write my 
 own (which I have done.)  You're very correct that D is not a RAD 
 language, and I don't think it's intended to be one.
 

vision of the system resources): D is promissing a lot... really promissing good levels of abstraction without performance losting. I should be really confortable changing C# by D.
 Over time, different class or library frameworks will emerge for D, and 
 one will become popular.  Since this has not yet happened, most people 
 are not interested in the obvious comparison you've made - rather, in 
 the comparison for the future.
 

(server side)... Mango support for servlets is really a pleasure... this is my example about standards... why not to grow to other "server side" common resources (i.e. Data Base access,...)
 
 Just my opinion.
 
 Also, I disagree with your comments on C#; I don't believe it was 
 designed as the way to access the framework.  In fact, I think .NET 
 smells much stronger of Visual Basic .NET than of C#.  But that's really 
 an opinion.
 
 Further, C#'s syntax and features are actually represented in a standard 
 which would theoretically be framework agnostic, much like JavaScript. 
 AFAIK.

I'ts true, but I allways use de same example: .Net/Java Virtual Machine is to Machine the same than Framework is to de Operative System. ¿Who wants to program without S.O. support? No one I know works with C# without framework (no one I know :-/ )
 
 -[Unknown]
 

Nov 27 2006
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
antonio wrote:

 D community never will implement this "platform/framework" because they
 are interested in a practical exploration of possibilities not really in
 a serious productive alternative... this is work for other people... D
 is only the tool.

That is certainly a wrong conclusion. There is just so much infrastructure needed to build this framework, that it hasn't really been a viable possibility until maybe about now. Heady progress could possibly have been made, if the structure of the JDK or .Net had been more or less copied, but I think most people understand that this would put D ahead in anyway, even if the language itself was superior. D needs a framework that takes D and it's strengths into account. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Nov 26 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
antonio wrote:
 Frank Benoit (keinfarbton) wrote:
 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.

 What are concrete things that are better in D or C#? Can you make 
 examples?

best on c# framework documentation debugger Microsoft Integrated Developement Environment (IDE :-) ) Very good "guides" for framework extensibility (ex: connection with a different SGBD are very standardized...you can find really good implementations of ado.net for PostgreSQL, Firebird. D Database access is ridiculous... because D has not a proposal for standard database connectivity )

What about all of the C DB libs. out there? D can use those whereas C# really can't (well, it could, but with poor performance (interop), which would defeat the purpose).
 
 D:
 *has not an standard framework (has not the "rules" for a standard 
 framework extensibility)
 *documentation:  if you are not talking about D compiler, you have not 
 really "massive" framework/libraries/extensions to document... and the 
 ones you have are poorly documented (forums are the main "documentation" 
 repository)
 *not native debugger.
 *Poor IDEs(syntax highlight and so on... nothing really ).
 
 
 D weakness... is just the things you need to be productive:  No one 
 want's to work in a unique framework... in a unique "path"... in a 
 required D-Fundation: D people is more worried about Linux vs Windows 
 than D productivity.
 

Right, but libraries aside, I think one could be as productive with D as almost any other language on Linux where it's pretty common (and often as productive) to just use a good editor as your 'IDE'. D will probably take hold on Linux faster than in the Windows world for a myriad or reasons anyhow.
 
 

Nov 23 2006
parent Antonio <antonio abrevia.net> writes:
Dave escribi:
 antonio wrote:
 Frank Benoit (keinfarbton) wrote:
 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.

 What are concrete things that are better in D or C#? Can you make 
 examples?

best on c# framework documentation debugger Microsoft Integrated Developement Environment (IDE :-) ) Very good "guides" for framework extensibility (ex: connection with a different SGBD are very standardized...you can find really good implementations of ado.net for PostgreSQL, Firebird. D Database access is ridiculous... because D has not a proposal for standard database connectivity )

What about all of the C DB libs. out there? D can use those whereas C# really can't (well, it could, but with poor performance (interop), which would defeat the purpose).

compatibility must not forece us to "think" on C APIS... (imagine using 8086 non protected model... i386 allows you to do it, but you can't imagine a good operative system without CPU memory protection support becaus he has to mantain "backward" compatibility with 8086 memory model). The main thing here is "unified way to"... there is a lot of C libraries for data acces... The "lovely" way is to select only one standarization choice (Object Orientation, please): escape of simple C libraries API... free your mind. C Database libraries are the basis. D OOFramework is the infraestructure "high" level programmers need.
Nov 24 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Frank Benoit (keinfarbton) wrote:
 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.
 
 What are concrete things that are better in D or C#? Can you make examples?

I honestly think you cannot write an objective comparison if you don't have experience writing C# applications/programs. I just wanna comment on what Andrey wrote as well: Andrey Khropov wrote:
 Frank Benoit (keinfarbton) wrote:
 I think the biggest thing is that you have no metaprogramming support 

 (only type-parametrized classes and functions via generics) whereas 

 templates in D.

 Plus DbC and built-in unit testing.

 Another good thing C# lacks is aliases (AFAIK only namespace aliases are
 supported) and strong typedefs.

Well, so what? Just because it doesn't have meta programming doesn't mean D is better than C#. Maybe it actually means the opposite. I mean, you can't put that kind of thing in an article and hope that it will attract programmers to D. One might even argue that having a unittest framework is better than a built-in unittest construct. Same applies for aliases and string typedefs.
Nov 23 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Frank Benoit (keinfarbton) wrote:
 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.
 
 What are concrete things that are better in D or C#? Can you make examples?

I'm just going to compare languages because a comparison between .NET's Base Class Library and Phobos isn't fair anyway. This isn't an exhaustive list, is just what I remembered at the moment. D vs C# 2.0 Generics / templates are a lot more powerful in D. In C#, for a generic parameter you can only call methods defined on Object unless you tell the compiler that it will be of a predefined (base) class witch pretty much defeats the purpose of a generic class in most cases. This limitation makes generics useful mostly for container types and impedes advanced meta-programming like what's available on D. Properties in C# are declared explicitly using special syntax. D looks for methods with certain signatures to implement properties. Some people prefer one style over the other but the result is pretty much the same. C# has partial classes witch allows split a class in several files. This can be handy, for example, for a code generator to safely modify a file while the user modifies another for the same class. D doesn't has any way of doing this. Events are a native construct on C#. D recently got a standard library module that implements Signals & Slots witch is a similar concept but it's not in the language like in C#. C# has anonymous delegates as does D but they managed to implement them as real closures so you can return them from a function. I use these a lot, they cut down work every where. In D returning a delegate or using it after the function ended is undefined and probably will get you an Access Violation. D has lazy parameter evaluation where one or more parameters of a function aren't evaluated until they are needed. Very useful feature and one coming straight from functional languages. C# doesn't have this feature. C# things that don't have an equivalent in D. * Syntax for nullable types. * Operator ?? for null testing. * yield operator D things that don't have an equivalent in C#. * Tupples. * Unions. * Mixins. * DBC. * Inline Assembler. D vs C# 3.0 Release date for C# 3.0 hasn't been announced yet. Walter announced a 1.0 version for January 1 of 2007. Extension methods in C# will allow you to add new methods for any type. So, if you want the String class to have a method that converts to camel convention you can add it and call it like s1.ToCamelCase(). D supports something like extension methods but only for arrays of any type, just declare a function with a parameter of the type you want to extend. Lambda expression are supported in both languages although the C# syntax is a little better. In C# 3.0 we will have Query Expressions. These are a kind of run-time syntax tree of any code block you declare as a query expression and pass it around to methods, serialize it or compile and execute it. If you've programmed in Lisp, you'll recognize this. In D... Not yet but we are getting there with Tupples. Je je. Language integrated query (LINQ) witch more or less is SQL integrated in the language. In C# 3.0 it is implemented as syntax-tree transformations to the features described before. Cool stuff. Nothing like this in D has been discussed. As far as I know, generics weren't improved much on C# 3.0 so D still beats C#s a** on this. Hope this helps. -- Julio Csar Carrascal Urquijo
Nov 23 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Julio Csar Carrascal Urquijo wrote:
 

 
 C# has partial classes witch allows split a class in several files. This 
 can be handy, for example, for a code generator to safely modify a file 
 while the user modifies another for the same class. D doesn't has any 
 way of doing this.
 

Actually, I think you can achieve the same effect in D using mixins. -------------- template CodeGenerator_Class_Part() { //declarations ... } -------------- template Class_Coder_Part() { //declarations } -------------- class Class { mixin CodeFenerator_Class_Part!(); mixin Class_Coder_Part!(); } -------------- I think each of these can be in a separate file.
Nov 23 2006
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Hasan Aljudy wrote:
 Actually, I think you can achieve the same effect in D using mixins.
 
 --------------
 template CodeGenerator_Class_Part()
 {
     //declarations ...
 }
 --------------
 template Class_Coder_Part()
 {
     //declarations
 }
 --------------
 class Class
 {
     mixin CodeFenerator_Class_Part!();
     mixin Class_Coder_Part!();
 }
 --------------
 
 I think each of these can be in a separate file.

Not quite. Methods aren't imported from the mixin and don't participate in function overloading unless they are explicitly aliased, if I remember correctly.
Nov 24 2006
prev sibling next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Thanks for spending the time to write these things down.
It really helps me.
Nov 24 2006
parent =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
Frank Benoit (keinfarbton) wrote:
 Thanks for spending the time to write these things down.
 It really helps me.

Your welcome.
Nov 24 2006
prev sibling parent reply Marcio <mqmnews123 sglebs.com> writes:
Julio C=E9sar Carrascal Urquijo wrote:
 C# things that don't have an equivalent in D.
 * yield operator

I'd like to point out that the Concurrency and Coordination Runtime=20 (CCR) makes heavy use of yield. "The Concurrency and Coordination Runtime (CCR) is a lightweight=20 port-based concurrency library for C# 2.0 developed by George=20 Chrysanthakopoulos in the Advanced Strategies group at Microsoft. Here=20 http://channel9.msdn.com/ShowPost.aspx?PostID=3D143582 , we have a deep=20 discussion about CCR with George, a Software Architect, and Satnam=20 Singh, Architect. You can get more info about CCR on the CCR Wiki=20 http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime . = This is super cool stuff and represents a really innovative approach to=20 making managed threaded programming more readily understandable and=20 predictable. Please check out the OOPSLA/SCOOL paper on the CCR=20 http://research.microsoft.com/~tharris/scool/papers/sing.pdf . Click here http://channel9.msdn.com/Showpost.aspx?postid=3D206574 to see = how the CCR is being used by the Microsoft Robotics Group." CCR Programming http://channel9.msdn.com/ShowPost.aspx?PostID=3D219308 * article:=20 http://msdn.microsoft.com/msdnmag/issues/06/09/ConcurrentAffairs/default.= aspx
 D things that don't have an equivalent in C#.
 * Tupples.

It would be nice if the article compared to Eiffel as well. Eiffel has=20 DbC, generics, Tuples, agents, etc. marcio
Nov 24 2006
next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
On Fri, 24 Nov 2006 07:42:30 -0800, Marcio <mqmnews123 sglebs.com> wrote:

 Julio Csar Carrascal Urquijo wrote:
 C# things that don't have an equivalent in D.
 * yield operator

I'd like to point out that the Concurrency and Coordination Runtime (CCR) makes heavy use of yield. "The Concurrency and Coordination Runtime (CCR) is a lightweight port-based concurrency library for C# 2.0 developed by George Chrysanthakopoulos in the Advanced Strategies group at Microsoft. Here http://channel9.msdn.com/ShowPost.aspx?PostID=143582 , we have a deep discussion about CCR with George, a Software Architect, and Satnam Singh, Architect. You can get more info about CCR on the CCR Wiki http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime . This is super cool stuff and represents a really innovative approach to making managed threaded programming more readily understandable and predictable. Please check out the OOPSLA/SCOOL paper on the CCR http://research.microsoft.com/~tharris/scool/papers/sing.pdf . Click here http://channel9.msdn.com/Showpost.aspx?postid=206574 to see how the CCR is being used by the Microsoft Robotics Group." CCR Programming http://channel9.msdn.com/ShowPost.aspx?PostID=219308 * article: http://msdn.microsoft.com/msdnmag/issues/06/09/ConcurrentAffairs/default.aspx
 D things that don't have an equivalent in C#.
 * Tupples.

It would be nice if the article compared to Eiffel as well. Eiffel has DbC, generics, Tuples, agents, etc. marcio

Is this just me, or does this just look like CSP with a face-lift? Even the name "CCR" seems designed to look like "CSP" I wish MS would credit the orinigation of their work, rather than advertising the work as their own. Furthermore, I think this has been discussed here several times before. -JJR
Nov 24 2006
parent Marcio <mqmnews321 sglebs.com> writes:
John Reimer wrote:
 Is this just me, or does this just look like CSP with a face-lift?

CSP as a library using yield to achieve continuation-passing style the easy way, plus extra features.
 I wish MS would credit the orinigation of their work, rather than 
 advertising the work as their own.  Furthermore, I think this has been 
 discussed here several times before.

Well, Hoare now works for them anyway. "He is now an Emeritus Professor there, and is also a senior researcher at Microsoft Research in Cambridge, England." http://en.wikipedia.org/wiki/C._A._R._Hoare http://research.microsoft.com/users/thoare/ marcio
Nov 25 2006
prev sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Marcio wrote:
 Julio Csar Carrascal Urquijo wrote:
 C# things that don't have an equivalent in D.
 * yield operator

I'd like to point out that the Concurrency and Coordination Runtime (CCR) makes heavy use of yield.

Didn't know that. Thanks for the info. The yield operator in C# it's another time-saver and I probably should have written more about it. One of the coolest thing I wrote with yield was an encapsulation of several loops that iterated over the fields of an object using reflection. All of them needed some start, finish and filtering conditions but the code was very similar. I started writing a class that implemented IEnumerator and splitting the loop to implement the interface was starting to get very hard. Then I remembered yield and the IEnumerable interface and everything got converted to a single method and a couple of properties. Something like: class FieldInfoEnumerable : System.Collections.Generic.IEnumerable<FieldInfo> { public IEnumerator<FieldInfo> GetEnumerator() { Type type = m_initialType; do { foreach (FieldInfo fi in type.GetFields(m_bindingFlags)) yield return fi; type = type.BaseType; } while (type != m_finalType); } } The compiler made the hard work and converted the loop into a IEnumerator for me. I wish D had a yield operator. Maybe for D 2.0. I'm reading the OOPSLA pdf and downloading the videos right now. Thanks again.
Nov 24 2006
parent Daniel Keep <daniel.keep+lists gmail.com> writes:
Julio Csar Carrascal Urquijo wrote:
 ...  I wish D had a yield operator. Maybe for D 2.0.

Afraid I don't have the links on me, but Google for and look at StackThreads; specifically the coroutine module. That lets you write coroutines that use a yield *function*. D doesn't need yield to be an operator: we get by just fine writing it as a library. And I'm fairly sure you can't do that in C# :3 -- Daniel
Nov 26 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Frank Benoit (keinfarbton) wrote:
 I want to write an article about D. Therefore I want to show more
 details and advantages of D compared to C++, Java and C#. But I never
 used C#.
 
 What are concrete things that are better in D or C#? Can you make examples?

Take a look at this: http://en.wikipedia.org/wiki/C_Sharp#C.23_3.0_new_language_features Seems that D already has most of the new C# 3.0 features, except the major one (LINQ). Those would be good to point out.
Nov 23 2006
prev sibling parent Samuel MV <samuel jxdesigner.com> writes:
I've programmed a little bit in both, and from my very personal point of 
view ;-) ...

Better in C#:
- Nice debugger
- Lots of libraries with tons of functionalities
- Lots of books, code and tutorials for learning


Better in D:
- Speed + Expresiveness
- No need to install 100 MB framework in every computer
- KISS: as I've said before I'm tired of spending my time searching in 
the standard library to find out how to use correctly a 
'AbstractWriterAbstractFactoryGeneratorAddAnotherLongNameHere' ;-)


About IDEs: I'll be happy with a version of the olde VMS ISPF editor 
with some Rexx macros :)
Nov 24 2006