View mode: basic / threaded / horizontal-split · Log in · Help
March 30, 2008
Re: Why I Use D
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
Re: Why I Use D
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
Re: Why I Use D
"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
Re: Why I Use D
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
Re: Why I Use D
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
Re: Why I Use D
"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
Re: Why I Use D
"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 .
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home