March 30, 2008
What initially got me into D was seeing it as C++ without seperate header files - which when ur not using an IDE is a HUGE plus in my opinion.

Not surprisingly it has many similarities to C# and from reading other posts here I think C# would suit a lot of people, however naturally the .NET framework may be an issue there and honestly the more I use C# the more I'm beginning to hate it - and love D =)

With regularity can you hear me exclaiming to my coworkers "this would not be a problem if we were only using D".

Const-wise, I think I'm quite a fan of the recent const implementation - just can't wait for full integration into libs and operator overloading =)


March 30, 2008
Neil Vice>the more I use C# the more I'm beginning to hate it - and love D =)<

I like D more than C# (despite C# 3.0+ has some things I may like, like the syntax of properties, the syntax of lambdas, LINQ, the help the IDE gives you, the automatic support of multi core, the fact that it's used by more people, the syntax of the "foreach", its associative arrays, some parts of its standard library, some of its compilation at run-time, and few other bits. Among such things some of them can be added into D too).

Have you written few benchmarks to compare the performance of the garbage collector and the associative arrays of C# on dotnet, to those of D (DMD, Phobos)?

Bye,
bearophile
March 31, 2008
"bearophile" <bearophileHUGS@lycos.com> wrote in message news:fsnu26$1a1u$1@digitalmars.com...
> Neil Vice>the more I use C# the more I'm beginning to hate it - and love D =)<
>
> I like D more than C# (despite C# 3.0+ has some things I may like, like the syntax of properties, the syntax of lambdas, LINQ, the help the IDE gives you, the automatic support of multi core, the fact that it's used by more people, the syntax of the "foreach", its associative arrays, some parts of its standard library, some of its compilation at run-time, and few other bits. Among such things some of them can be added into D too).

I do like the property syntax of C#, though as much as the equivalence with methods in D has the potential to be confusing, with coding conventions I think it could work quite well.

The IDE is obviously a big plus and as such I wouldn't attempt a regular GUI-based Windows app in D myself, I find the IDE pretty unnecessary for console-based development - a decent debugger not-withstanding.

Run-time compilation can be frustrating - it obfuscates profiling and requires (as far as I'm aware) digital signing etc. to forcibly pre-compile for performance.

> Have you written few benchmarks to compare the performance of the garbage collector and the associative arrays of C# on dotnet, to those of D (DMD, Phobos)?

I haven't written any benchmarks no. What I have observed using C# is simply that it's performance is "lower than I would expect". Porting code from Delphi has resulting in typically neater, but slower code. Just the control that D provides compared to C# and the fact that it is compiled directly to machine code mean that D is basically guaranteed to be faster provided sufficient effort is put in if you know what I mean.

I suppose another thing that makes me look more favourable upon D is that my expectations are lower in certain areas. If a phobos method does something a bit strange I'm forgiving... if a .NET method which you expect to be thoroughly documented in the MSDN library throws an exception which is not in the list of exceptions that it should be able to throw, I get pretty annoyed =P


March 31, 2008
Neil Vice:

>Run-time compilation can be frustrating - it obfuscates profiling and requires (as far as I'm aware) digital signing etc. to forcibly pre-compile for performance.<

But it allows you to do some things that aren't easy to do with D (recently you may have seen two libs to do similar things in D).


>Just the control that D provides compared to C# and the fact that it is compiled directly to machine code mean that D is basically guaranteed to be faster provided sufficient effort is put in if you know what I mean.<

That's a myth. I have personally found situations where that's very false. D AAs and GC are sometimes slower or much slower, etc.

Bye,
bearophile
March 31, 2008
Neil Vice wrote:
> ...
> that D provides compared to C# and the fact that it is compiled directly to machine code mean that D is basically guaranteed to be faster 

No-one should write such a thing. Benchmarking is an empirical black art
and there are absolutely no guarantees whatsoever...

Helmut
April 01, 2008
"bearophile" <bearophileHUGS@lycos.com> wrote in message news:fsqit4$67p$1@digitalmars.com...
>>Just the control that D provides compared to C# and the fact that it is compiled directly to machine code mean that D is basically guaranteed to be faster provided sufficient effort is put in if you know what I mean.<
>
> That's a myth. I have personally found situations where that's very false. D AAs and GC are sometimes slower or much slower, etc.

My point was not that D is guaranteed to be faster out-of-the-box by any means. The difference is that if you want to improve the performance of C# beyond a certain point you have to resort to writing a library in C for example which you can then call from C#. With D on the other hand you can write this code directly in D.

If the built-in D GC is slower you can replace it; I believe Tango has already done this. Could you do this in .NET?

If the D AAs are slow you have the option to write whatever task-specific data structure you like that can be implemented in assembly if you wish. In .NET you are limited by the performance of the VM.

Perhaps when criticising C# I am in fact criticising .NET. It is possible that there is nothing in the C# specification which precludes writing a direct-to-machine-code compiler and a corresponding replacement standard-library, but this is a lot more work than writing your own AA template.


April 01, 2008
"Helmut Leitner" <leitner@wikiservice.at> wrote in message news:fsql7g$cpr$1@digitalmars.com...
> Neil Vice wrote:
>> ...
>> that D provides compared to C# and the fact that it is compiled directly
>> to machine code mean that D is basically guaranteed to be faster
>
> No-one should write such a thing. Benchmarking is an empirical black art and there are absolutely no guarantees whatsoever...

That's like saying that the outcome is entirely non-deterministic. Just because the problem may be complex doesn't mean there are no guarantees.

Essentially my point is that, because C# & .NET impose more limitations and allow less control than D, assuming the best-case scenario for both languages D will win out.

Alternatively I would have said that best-case C and D are probably equivalent as both languages can get incredibly close to assembler.

To be more specific, let's say you were to hand-code a routine in assembler for a specific architecture such that you had (ideally) obtained the optimal implementation. If D has embedded assembly support for the architecture then you can achieve the exact same result in D. If this support does not exist you could probably get quite close with a combination of intrinsics and careful (probably involving trial and error) implementation. I would suggest that, even with precompiled binaries, you would be very hard-pressed to achieve a similar result using C#/.NET .


1 2
Next ›   Last »