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.

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.

> 
> 

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.

Julio César Carrascal Urquijo wrote:
> 
<snip>
> 
> 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.

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.

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'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 :)

Thanks for spending the time to write these things down.
It really helps me.

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).
Object Orientation give us the posibility of a great API:  "backwards" 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.

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