www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Coolest D features

reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Say you wanted to introduce a programmer friend to D. She might know one 

too much on that. What features of D would you describe first to hook 
that friend in?

Andrei
Dec 26 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Andrei Alexandrescu (See Website For Email)" 
<SeeWebsiteForEmail erdani.org> wrote in message 
news:45917146.9020008 erdani.org...

 Say you wanted to introduce a programmer friend to D. She might know one 

 much on that. What features of D would you describe first to hook that 
 friend in?


It might not sound like much, but built-in associative arrays and dynamic 
arrays.  I have never found a more powerful combination of containers.  I 
can do so much with just these two types.
Dec 26 2006
prev sibling next sibling parent Xinok <xnknet gmail.com> writes:
Arrays:
Built-in Dynamic and Associative Arrays
Slicing [..]
Concatenation ~

Nested Functions - Which can access everything in the parent function

Mixins

Static If

Lazy Arguments

Tuples

And best of all - No runtime required!
Dec 26 2006
prev sibling next sibling parent Waldemar <waldemar wa-ba.com> writes:

So
for them it's speed.

For C/C++, I would go with class design (by reference only, garbage colleted,
always virtual, easy initialization) and still mention speed.
Dec 26 2006
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?
 
 Andrei



native code speed with the ease of development offered by built-in 
garbage collection.  After that come niceties like nested functions and 
class delegates.  And if you're into templates then D's templates are 
very nice and enable a lot of nifty things that are difficult to do in 
C++ -- (static if! variadic templates & tuples!).  The lack of need for 
header files is another plus.  It gets very tiring having to type every 
function signature twice in C++.

There are lots of other little minor things that make D nicer to use 
than C/C++ and other alternatives (I put built-in arrays in this 
category), but to me those aren't the biggies.

The ability to call C code without a lot of messy JNI-like boilerplate 
code is also a big deal.


I wholeheartedly agree with Waldemar, though, that the things that are 
going to sway C/C++ folks are different from what's going to sway 


the other hand, if they find they need to deliver an app that works 
stand-alone, independent of a 100MB runtime environment, or one which 
runs at native speed, then D is probably the closest thing they're going 


--bb
Dec 26 2006
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Bill Baxter wrote:

 I wholeheartedly agree with Waldemar, though, that the things that are 
 going to sway C/C++ folks are different from what's going to sway 


 the other hand, if they find they need to deliver an app that works 
 stand-alone, independent of a 100MB runtime environment, or one which 
 runs at native speed, then D is probably the closest thing they're going 

 


Being a long time Java programmer, I strongly disagree with you and 
Waldemar both. Speed is only an issue for people who don't use Java, or 
for those who don't really know how to properly write software with it. 
Most Java programmers I know, myself included, call the "Java is slow" 
mantra a myth. Java *used to* be slow, true. Today, it's possible to 
code a clunky app in Java if you don't know what you are doing. But the 
reality is that it's plenty fast in the general case. Plus, Java 
programmers swear by runtime compilation. And each release of Sun's 
Hotspot compiler, coupled with bug fixes and enhancements in the 
standard APIs, ups performance. So if you want to woo them, focusing on 
speed is not the way to do it. That would be more likely to turn them 
off, if not make them outright perturbed (oh, here we go again, another 
"Java is slow" moron).
Dec 27 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Mike Parker wrote:

 Being a long time Java programmer, I strongly disagree with you and 
 Waldemar both. Speed is only an issue for people who don't use Java, or 
 for those who don't really know how to properly write software with it. 
 Most Java programmers I know, myself included, call the "Java is slow" 
 mantra a myth. Java *used to* be slow, true. Today, it's possible to 
 code a clunky app in Java if you don't know what you are doing. But the 
 reality is that it's plenty fast in the general case. Plus, Java 
 programmers swear by runtime compilation. And each release of Sun's 
 Hotspot compiler, coupled with bug fixes and enhancements in the 
 standard APIs, ups performance. So if you want to woo them, focusing on 
 speed is not the way to do it. That would be more likely to turn them 
 off, if not make them outright perturbed (oh, here we go again, another 
 "Java is slow" moron).


I haven't worked with Java for over 10 years now. But in March I 
attended "Java Performance Myths" by Brian Goetz, who is very 
knowledgeable about getting the most out of Java. He indicated that Java 
  needed another 10 years before it would be able to consistently match 
C toe to toe. And this is happening despite years of massive investment 
in Java by lot of very smart people, just to approach what relatively 
simple C compilers can do. This to me indicates there's a fundamental 
problem with Java.

I think the problem is that Java is just lacking in some needed features 
- like a full set of basic types, simple aggregates, out parameters, 
etc. The alternatives are computationally expensive, and so the 
optimizer has a lot of work to do to reverse engineer them and figure 
out that all the programmer was doing was a workaround for a POD stack 
aggregate.

Java also has a few millstones that make things difficult for optimizers 
- the required array bounds checking, the VM, etc.

C++, much promoted for its efficiency, has a subtle problem with 
efficiency. We all know that the biggest gains in efficiency come from 
algorithmic improvements. But C++'s strength is in optimizing not the 
algorithms, but the micro-optimization details of implementing them. C++ 
code tends to get so complex that once we get it to work, we dare not go 
tinkering with the overall algorithm, but just concentrate on twiddling 
with the micro-optimizations.

I discovered this when working on DMDScript. I had spent a great deal of 
time tinkering with the details of the C++ version trying to make it go 
faster. Then I translated it to D, and found myself instead of tinkering 
with the low level details, I was tinkering with the algorithms. With a 
few changes there, that would have been hard to retrofit into the C++ 
code, I had it running faster than the C++ one.

And that may be D's efficiency trump card over C++ - it's much easier to 
modify existing, working code in ways that are too risky to do with C++.
Dec 27 2006
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Walter Bright wrote:


 
 I haven't worked with Java for over 10 years now. But in March I 
 attended "Java Performance Myths" by Brian Goetz, who is very 
 knowledgeable about getting the most out of Java. He indicated that Java 
  needed another 10 years before it would be able to consistently match C 
 toe to toe. And this is happening despite years of massive investment in 
 Java by lot of very smart people, just to approach what relatively 
 simple C compilers can do. This to me indicates there's a fundamental 
 problem with Java.


I've never heard Brian Goetz speak, but he's a prolific writer. One of 
his articles, Urban Performance Legends 
(http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html), is 
one I often direct people to in Java performance discussions. But the 
question one must ask when evaluating any language is, what is this 
language suitable for? When you look at everything Java gives you, the 
trade-off of not matching performance of C is acceptable for a wide 
range of applications, but not everything under the sun (no pun intended).

Books like Code Complete and Writing Secure Code exist because languages 
like C and C++ have no built-in mechanisms to prevent severe errors like 
buffer overruns. How many times does this happen in server applications 
or even non-networking libraries? libpng had a patch recently, last year 
I believe, to fix a buffer overrun. That just shouldn't be happening itn 
modern software. Java's answer to those issues is certainly extreme, but 
a lot of people find that beneficial -- particularly for network 
software. I've written a lot of C code and a lot of Java code. It's much 
more pleasant to write Java because I can write a lot less of it. I 
don't mind a bit that it's not going to beat C in the performance arena 
because I don't need it to for what I use it for.

One of the things I like about D is that it incorporates some of the 
same mechanisms, but in a more flexible way (i.e. array bounds checking 
can be turned off). One of the things I miss about Java when I use D is 
the ability to instantiate any class by name. I've made heavy use of 
that for some component-based designs in Java. Designing D applications 
requires me to think differently, much as Java required a new way of 
thinking when coming from C.


 
 I think the problem is that Java is just lacking in some needed features 
 - like a full set of basic types, simple aggregates, out parameters, 
 etc. The alternatives are computationally expensive, and so the 
 optimizer has a lot of work to do to reverse engineer them and figure 
 out that all the programmer was doing was a workaround for a POD stack 
 aggregate.
 
 Java also has a few millstones that make things difficult for optimizers 
 - the required array bounds checking, the VM, etc.


I have no background at all in language design, or optimizers, but I'm 
guessing it's more than just a language feature issue. Most of Java's 
critical optimizations happen at runtime during the runtime analysis and 
compilation phases. Runtime compilation is still a comparatively young 
technology in practice. There are still a lot of kinks to be worked out 
in the process, a lot of progress to be made. I assume when Goetz said 
Java's performance would match C in 10 years, he was specifically 
referring to the Hotspot VM, or runtime compilation in general.

There are two VMs that ship with the SDK, referred to as the client and 
server VMs. The client VM has a shorter runtime analysis period than the 
server VM, so the server VM can make more aggressive optimizations after 
longer periods of analysis. I've read that it can eliminate array bounds 
checks in certain cases. Whatever it does, Java's runtime optimizations 
are built around the language's features. For example, in the latest 1.6 
release they just laid the groundwork for escape analysis, which will 
eliminate some object allocations on the heap and move them to the 
stack. The full implementation should be available in 1.7. I've even 
heard rumors that a JSR for a struct type will make it into a future 
release, which could open the door for more optimizations and, possibly, 
features like out parameters.


 
 C++, much promoted for its efficiency, has a subtle problem with 
 efficiency. We all know that the biggest gains in efficiency come from 
 algorithmic improvements. But C++'s strength is in optimizing not the 
 algorithms, but the micro-optimization details of implementing them. C++ 
 code tends to get so complex that once we get it to work, we dare not go 
 tinkering with the overall algorithm, but just concentrate on twiddling 
 with the micro-optimizations.
 
 I discovered this when working on DMDScript. I had spent a great deal of 
 time tinkering with the details of the C++ version trying to make it go 
 faster. Then I translated it to D, and found myself instead of tinkering 
 with the low level details, I was tinkering with the algorithms. With a 
 few changes there, that would have been hard to retrofit into the C++ 
 code, I had it running faster than the C++ one.
 
 And that may be D's efficiency trump card over C++ - it's much easier to 
 modify existing, working code in ways that are too risky to do with C++.


But that's a completely different world. When trying to win over C++ 
programmers, words like efficiency, optimization, and performance carry 
a great deal of weight. Speed is king. Not so in the Java community. 
It's a different mindset with different goals. If Java programmers were 
overly concerned about performance, they wouldn't be using Java. Sure, 
they want their software to be performant and a good Java programmer 
knows how to squeeze every ounce of performance out of his code, but 
performance alone isn't going to sway them.

I think that overall D is going to be an easier sell to C++ programmers 
than to Java types. They are two very different markets that will 
require very different strategies.
Dec 27 2006
parent reply Waldemar <waldemar wa-ba.com> writes:
== Quote from Mike Parker (aldacron71 yahoo.com)'s article
[snip]

 I think that overall D is going to be an easier sell to C++ programmers
 than to Java types. They are two very different markets that will
 require very different strategies.



freqency of these cases, performance forces the use of another language.  D
would
be a candidate for that other language.  It is the only situation where
pitching D


D is a low level language competing with C/C++/ASM.

It has a chance but I don't know how long the window of opportunity will last.
Dec 27 2006
parent BCS <BCS pathilink.com> writes:
Waldemar wrote:

 == Quote from Mike Parker (aldacron71 yahoo.com)'s article
 [snip]

 I think that overall D is going to be an easier sell to C++ programmers
 than to Java types. They are two very different markets that will
 require very different strategies.


 

 freqency of these cases, performance forces the use of another language.  


Also in cases needing ASM access or where use of a VM is not an option.

The first case won't go away and the second could come into play when, 
for an example, it takes longer to load the VM than it does to run the 
app, or when size is a BIG issue. I'll admit that D doesn't yet excel in 
either of these last two cases, but it will (I hope), I don't think 



 D would
 be a candidate for that other language.  It is the only situation where
pitching D

 
 D is a low level language competing with C/C++/ASM.
 
 It has a chance but I don't know how long the window of opportunity will last.
Dec 27 2006
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
Walter Bright wrote:

 I think the problem is that Java is just lacking in some needed features 
 - like a full set of basic types, simple aggregates, out parameters, 
 etc. The alternatives are computationally expensive, and so the 
 optimizer has a lot of work to do to reverse engineer them and figure 
 out that all the programmer was doing was a workaround for a POD stack 
 aggregate.


Could you expand on the above items?  What basic types are missing? 
Does a "simple aggregate" refer to structs/tuples?  What does POD stand 
for, and what is a POD stack aggregate?  Could you show a code example 
in D that performs badly in Java?  Pardon my ignorance.

-Jeff
Dec 27 2006
next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Jeff Nowakowski" <jeff dilacero.org> wrote in message 
news:emum7l$21kg$1 digitaldaemon.com...

 Walter Bright wrote:

 I think the problem is that Java is just lacking in some needed 
 features - like a full set of basic types, simple aggregates, out 
 parameters, etc. The alternatives are computationally expensive, and so 
 the optimizer has a lot of work to do to reverse engineer them and figure 
 out that all the programmer was doing was a workaround for a POD stack 
 aggregate.


 Could you expand on the above items?  What basic types are missing? Does a 
 "simple aggregate" refer to structs/tuples?  What does POD stand for, and 
 what is a POD stack aggregate?  Could you show a code example in D that 
 performs badly in Java?  Pardon my ignorance.

 -Jeff


Unsigned types are missing in Java.  POD means plain old data.  Walter is 
talking about D's structs which are instantiated on the stack instead of the 
heap.  Currently, Java has no way of allocating an aggregate data structure 
on the stack, although I hear that Sun is working on it.

-Craig
Dec 27 2006
parent Mike Parker <aldacron71 yahoo.com> writes:
Craig Black wrote:


 
 Unsigned types are missing in Java.  POD means plain old data.  Walter is 
 talking about D's structs which are instantiated on the stack instead of the 
 heap.  Currently, Java has no way of allocating an aggregate data structure 
 on the stack, although I hear that Sun is working on it.
 
 -Craig 


It's called escape analysis. You can read a bit about it in this article 
by Brian Goetz: 
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html. And 
it has been implemented for the first time in the latest version of 
Java, 1.6.
Dec 27 2006
prev sibling next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jeff Nowakowski wrote:

 Walter Bright wrote:

 I think the problem is that Java is just lacking in some needed 
 features - like a full set of basic types, simple aggregates, out 
 parameters, etc. The alternatives are computationally expensive, and 
 so the optimizer has a lot of work to do to reverse engineer them and 
 figure out that all the programmer was doing was a workaround for a 
 POD stack aggregate.


 
 Could you expand on the above items?


I'm not Walter, but I can answer most of these:


 What basic types are missing?


The unsigned ones,


 Does a "simple aggregate" refer to structs/tuples?


Structs, probably.


 What does POD stand for, 


Plain Old Data, e.g. ints, chars, floats, C-style structs (that contain 
only POD members).
Classes aren't POD types (in D and Java) because they have virtual 
functions which requires a vtable, disqualifying them.


 and what is a POD stack aggregate?


A POD aggregate stored on the stack if possible, i.e. a C or D struct 
(with only POD members).


 Could you show a code example in D that performs badly in Java? 


Pardon my ignorance.

Sorry, can't help there. I haven't used Java in a couple of years...
Dec 27 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Jeff Nowakowski wrote:

 Walter Bright wrote:

 I think the problem is that Java is just lacking in some needed 
 features - like a full set of basic types, simple aggregates, out 
 parameters, etc. The alternatives are computationally expensive, and 
 so the optimizer has a lot of work to do to reverse engineer them and 
 figure out that all the programmer was doing was a workaround for a 
 POD stack aggregate.


 
 Could you expand on the above items?  What basic types are missing? Does 
 a "simple aggregate" refer to structs/tuples?  What does POD stand for, 
 and what is a POD stack aggregate?


POD = Plain Old Data.  In D, a struct is a POD stack aggregate.  And I'm 
not sure what Walter meant about basic types, but I've been occasionally 
annoyed at the lack of unsigned primitives in Java.  The out parameter 
issue (or a lack of tuples) is another one.  It's really not uncommon to 
want to return/alter two values in a function call, particularly in the 
case of recursion.  That said, it's obviously possible to re-engineer a 
design to account for this, but the elegant approach often seems to 
sacrifice some degree of efficiency.


Sean
Dec 27 2006
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright wrote:

 I haven't worked with Java for over 10 years now. But in March I 
 attended "Java Performance Myths" by Brian Goetz, who is very 
 knowledgeable about getting the most out of Java. He indicated that Java 
  needed another 10 years before it would be able to consistently match C 
 toe to toe. And this is happening despite years of massive investment in 
 Java by lot of very smart people, just to approach what relatively 
 simple C compilers can do. This to me indicates there's a fundamental 
 problem with Java.



In a head to head C vs. D comparison on the computer go mailing list. 
It was reported that D was slower than C by a factor of 1.5.  That's 
close enough for me to consider D sufficiently fast.  I don't know how 
that compares to Java.

http://www.mail-archive.com/computer-go computer-go.org/msg00663.html
Dec 27 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jason House wrote:

 In a head to head C vs. D comparison on the computer go mailing list. It 
 was reported that D was slower than C by a factor of 1.5.  That's close 
 enough for me to consider D sufficiently fast.  I don't know how that 
 compares to Java.
 
 http://www.mail-archive.com/computer-go computer-go.org/msg00663.html


I bet that if they compared DMD with DMC, they'd have found no 
difference. If you write "C style" code in D, you will get exactly the 
same results you get from C.
Dec 27 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 Jason House wrote:
 

 In a head to head C vs. D comparison on the computer go mailing list. 
 It was reported that D was slower than C by a factor of 1.5.  That's 
 close enough for me to consider D sufficiently fast.  I don't know how 
 that compares to Java.

 http://www.mail-archive.com/computer-go computer-go.org/msg00663.html


 
 I bet that if they compared DMD with DMC, they'd have found no 
 difference. If you write "C style" code in D, you will get exactly the 
 same results you get from C.


The same guy elaborates a bit in

http://www.mail-archive.com/computer-go computer-go.org/msg00666.html

and it actually ends up sounding like it should have been posted in this 
thread.

A quote: "You can write code a little faster in D [than C], but you can
write finished bug-free code a LOT faster."
Dec 28 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 Jason House wrote:



 It was reported that D was slower than C by a factor of 1.5.


 
 I bet that if they compared DMD with DMC, they'd have found no 
 difference.


That makes it sound like DMC is 1.5 slower than your average C.
Dec 28 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Georg Wrede wrote:

 Walter Bright wrote:

 Jason House wrote:


 

 It was reported that D was slower than C by a factor of 1.5.


 I bet that if they compared DMD with DMC, they'd have found no 
 difference.


 
 That makes it sound like DMC is 1.5 slower than your average C.


Your average C? No. It might be 1.5 slower than the specific C compiler 
the benchmarker used for that specific application. Performance for 
particular applications varies all over the map for different C compilers.
Dec 28 2006
parent reply Waldemar <waldemar wa-ba.com> writes:
== Quote from Walter Bright (newshound digitalmars.com)'s article

 Georg Wrede wrote:

 Walter Bright wrote:

 Jason House wrote:



 It was reported that D was slower than C by a factor of 1.5.


 I bet that if they compared DMD with DMC, they'd have found no
 difference.


 That makes it sound like DMC is 1.5 slower than your average C.


 Your average C? No. It might be 1.5 slower than the specific C compiler
 the benchmarker used for that specific application. Performance for
 particular applications varies all over the map for different C compilers.


That may be but this specific C compiler is most likely gcc on Linux or VS C++
on
Windows.  The D compiler is probably dmd.  It's a bit shocking to see a 50%
difference.  Is there information which compilers were used?  And is there any
reason to believe the specifics of the benchmark could produce such a wide
difference?
Dec 28 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Waldemar wrote:

 == Quote from Walter Bright (newshound digitalmars.com)'s article

 Georg Wrede wrote:

 Walter Bright wrote:

 Jason House wrote:

 It was reported that D was slower than C by a factor of 1.5.


 I bet that if they compared DMD with DMC, they'd have found no
 difference.


 That makes it sound like DMC is 1.5 slower than your average C.


 Your average C? No. It might be 1.5 slower than the specific C compiler
 the benchmarker used for that specific application. Performance for
 particular applications varies all over the map for different C compilers.


 
 That may be but this specific C compiler is most likely gcc on Linux or VS C++
on
 Windows.  The D compiler is probably dmd.  It's a bit shocking to see a 50%
 difference.  Is there information which compilers were used?  And is there any
 reason to believe the specifics of the benchmark could produce such a wide
difference?


In the past it's been mentioned that DMD (and DMC by extension, I 
assume) produces somewhat sub-optimal code for floating-point ops, and 
there may be one or two other scenarios as well.  So any test that uses 
these features heavily may present a somewhat skewed display of language 
performance.


Sean
Dec 28 2006
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Waldemar schrieb am 2006-12-28:

<snip>


 That may be but this specific C compiler is most likely gcc on Linux or VS C++
on
 Windows.  The D compiler is probably dmd.  It's a bit shocking to see a 50%
 difference.  Is there information which compilers were used?  And is there any
 reason to believe the specifics of the benchmark could produce such a wide
difference?


Comparing SciMark2 (svn://dstress.kuehne.cn/benchmark/scimark) compiled
with GDC-0.20 and DMD-0.178 suggests that D is 71% faster than D <g>

GDC-0.20:
	Using       2.00 seconds min time per kernel.
	Composite Score:          366.95
	FFT             Mflops:   552.68    (N=1024)
	SOR             Mflops:   338.06    (100 x 100)
	MonteCarlo      Mflops:    63.91
	Sparse matmult  Mflops:   346.75    (N=1000, nz=5000)
	LU              Mflops:   533.33    (M=100, N=100)

DMD-0.178:
	Using       2.00 seconds min time per kernel.
	Composite Score:          213.89
	FFT             Mflops:   240.84    (N=1024)
	SOR             Mflops:   347.83    (100 x 100)
	MonteCarlo      Mflops:    48.63
	Sparse matmult  Mflops:   107.08    (N=1000, nz=5000)
	LU              Mflops:   325.08    (M=100, N=100)

The most important question of benchmarking:
What do you compare and why do you compare it?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFlCwrLK5blCcjpWoRAhdtAKCaGafUkKGjmBPukKBTid/03LLDAQCgrq+9
SUTvZKzinOVKtRxVwsNVGiA=
=4zbH
-----END PGP SIGNATURE-----
Dec 28 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Thomas Kuehne wrote:

 Waldemar schrieb am 2006-12-28:

 That may be but this specific C compiler is most likely gcc on
 Linux  or VS C++ on Windows. The D compiler is probably dmd.




Yes, most likely. This or that.


 It's a bit shocking to see a 50% difference. Is there information
 which compilers were used?




I suspect no foul play, but the Western Science Dogma of Repeatability 
simply demands that we be provided with enough information to "try this 
at home".


 And is  there any reason to believe the specifics of the benchmark
 could produce such a  wide difference?


 
 Comparing SciMark2 (svn://dstress.kuehne.cn/benchmark/scimark) compiled
 with GDC-0.20 and DMD-0.178 suggests that D is 71% faster than D <g>


While this quip is most entertaining, many in the audience may miss the 
point. Which, unfortunately, shrouds the issue altogether.


 GDC-0.20:
 DMD-0.178:
 	Using       2.00 seconds min time per kernel.
 	Using       2.00 seconds min time per kernel.
 	Composite Score:          366.95
 	Composite Score:          213.89
 	FFT             Mflops:   552.68    (N=1024)
 	FFT             Mflops:   240.84    (N=1024)
 	SOR             Mflops:   338.06    (100 x 100)
 	SOR             Mflops:   347.83    (100 x 100)
 	MonteCarlo      Mflops:    63.91
 	MonteCarlo      Mflops:    48.63
 	Sparse matmult  Mflops:   346.75    (N=1000, nz=5000)
 	Sparse matmult  Mflops:   107.08    (N=1000, nz=5000)
 	LU              Mflops:   533.33    (M=100, N=100)
 	LU              Mflops:   325.08    (M=100, N=100)
 
 
 The most important question of benchmarking:

 What do you compare, and why do you compare it?


An ancient folk wisdom from Sipoo, Finland: "A man with clean flour, 
never has to hide his palms."
Dec 28 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Waldemar wrote:

 == Quote from Walter Bright (newshound digitalmars.com)'s article

 Georg Wrede wrote:

 Walter Bright wrote:

 Jason House wrote:

 It was reported that D was slower than C by a factor of 1.5.


 I bet that if they compared DMD with DMC, they'd have found no
 difference.


 That makes it sound like DMC is 1.5 slower than your average C.


 Your average C? No. It might be 1.5 slower than the specific C compiler
 the benchmarker used for that specific application. Performance for
 particular applications varies all over the map for different C compilers.


 
 That may be but this specific C compiler is most likely gcc on Linux or VS C++
on
 Windows.  The D compiler is probably dmd.


If he's using gcc, he should do benchmark comparisons with gdc.


 It's a bit shocking to see a 50%
 difference.  Is there information which compilers were used?  And is there any
 reason to believe the specifics of the benchmark could produce such a wide
difference?


There's every reason to believe it. Often, people who write benchmarks 
never check to see exactly what they are actually benchmarking. I've 
seen all of the following:

1) using the wrong compiler switches
2) assuming one is testing string handling speed, when actually the 
benchmark was extremely sensitive to how the compiler handled the / 
operation on integers
3) assuming one is benchmarking some calculation speed, when one is 
actually benchmarking some innocuous looking C library function call
4) etc. etc.

In other words, you don't know what you're benchmarking until you run a 
profiler on it. And nobody runs profilers <g>. The old adage that 90% of 
your code execution time is in 10% of the code applies to benchmarks, 
too. Unless you actually dig in and measure it, sure as heck that 10% 
will not be where you think it is.
Dec 28 2006
prev sibling next sibling parent reply Waldemar <waldemar wa-ba.com> writes:
== Quote from Mike Parker (aldacron71 yahoo.com)'s article

 Bill Baxter wrote:

 I wholeheartedly agree with Waldemar, though, that the things that are
 going to sway C/C++ folks are different from what's going to sway


 the other hand, if they find they need to deliver an app that works
 stand-alone, independent of a 100MB runtime environment, or one which
 runs at native speed, then D is probably the closest thing they're going



 Being a long time Java programmer, I strongly disagree with you and
 Waldemar both. Speed is only an issue for people who don't use Java, or
 for those who don't really know how to properly write software with it.
 Most Java programmers I know, myself included, call the "Java is slow"
 mantra a myth. Java *used to* be slow, true. Today, it's possible to
 code a clunky app in Java if you don't know what you are doing. But the
 reality is that it's plenty fast in the general case. Plus, Java


Actually, the reality is Java is plenty slow in many applications. There is JNI
for a reason.  Never mind cases where Java is not even considered (fast servers,
OS internals, communication, graphics, driveres, embedded, etc, etc.)  As soon
as
Java reaches C/C++ speed, C++ will disappear.  Not too worry, won't happen any
time soon.

Having said that, there is always a danger that Sun develops "low level Java"
with
performance truly matching C++.   If that happens D might as well close the
shop.

"safer" C/C++ with many custom libs and features.  But you can feel it's just
one
more step, so watch out.




 programmers swear by runtime compilation. And each release of Sun's
 Hotspot compiler, coupled with bug fixes and enhancements in the
 standard APIs, ups performance. So if you want to woo them, focusing on
 speed is not the way to do it. That would be more likely to turn them
 off, if not make them outright perturbed (oh, here we go again, another
 "Java is slow" moron).
Dec 27 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Waldemar wrote:

 Actually, the reality is Java is plenty slow in many applications.
 There is JNI for a reason.  Never mind cases where Java is not even
 considered (fast servers, OS internals, communication, graphics,
 driveres, embedded, etc, etc.)  As soon as Java reaches C/C++ speed,
 C++ will disappear.  Not too worry, won't happen any time soon.


If a Java program has to do the same work as "the same" program in C++, 
and _additionally_ run a VM, do JIT compiling -- I can't see how it's 
even theoretically possible to "reach C/C++ speed".

Oh well, I guess it's everybody's constitutional right to claim to 
become one day "as fast" as C/C++. I've heard that claim ever since many 
here weren't even born.


 Having said that, there is always a danger that Sun develops "low
 level Java" with performance truly matching C++.   If that happens D



This is one of the places D should claim and occupy, Java on steroids or 
not. In other words, what would Java do if D's libraries and tools 
suddenly got equal to Java's?
Dec 27 2006
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Waldemar wrote:


 Actually, the reality is Java is plenty slow in many applications.


I don't know about that. I have seen some nasty, klunky Java programs, 
but my experience is that they are the exception rather than the rule. 
Netbeans and Eclipse both started out as klunkers, but neither is today.



 There is JNI for a reason.


JNI was developed for compatibility with legacy code. It was used in the 
early days as a performance optimization tool, but these days not so 
much. Even for Java games, JNI is used only to access native APIs like 
OpenGL, OpenAL, or DirectInput. The old Dirty Java article at Gamasutra 
lost its relevance with the release of Java 1.4.


 Never mind cases where Java is not even considered (fast servers,
 OS internals, communication, graphics, driveres, embedded, etc, etc.)  As soon
as
 Java reaches C/C++ speed, C++ will disappear.  Not too worry, won't happen any
 time soon.
 


I don't expect people to write device drivers or any other performance 
critical code in Java :) That's not what Java is intended for. It *is* 
quite prevalent in embedded systems -- your cell phone is most likely 
equipped with JME, and you may even have some form of Java in your DVD 
player. The PS3 is equipped with a limited version of Java.

Java isn't a bare-metal systems language, but it isn't *slow*. The 
reality is somewhere in the middle. It's slower than C++ in most cases, 
yes. But there are plenty of applications that can be written in Java 
where a 5%, 10% or even 20% performance difference isn't going to 
matter. With my interest in games, I love to point out Java games like 
Tribal Trouble, Puzzle Pirates, and Bang! Howdy, all of which are 3D 
games, or the shooters developed by Puppy Games which are 2D on OpenGL. 
Since the JVM is bundled with each of them, most people don't know or 
don't care that they are written in Java. Performance is just fine in 
each of them.

The preceding paragraph is the typical response you are going to get 
from a Java programmer when you say Java is slow. There's a lot going on 
behind the scenes in the JVM, as Walter mentioned, and Java programmers 
understand that. There's a trade-off between safety/security and speed. 
They accept that. Do you think anyone at all would choose Java if it 
truly was a snail at everything? They like the ease of writing 
concurrent applications in Java compared to other languages. They like 
Java's inherent networking capabilities. They like the advanced 
development tools available for the language, such as the free 
profilers, full-featured IDEs, and the ability to choose between and 
fine-tune for several different GC implementations to get the best 
performance possible. Some hardcore Java programmers might be willing to 
write a video or audio codec in Java, but most are more grounded and 
understand that Java isn't suited for that.

So my point is that Java programmers use Java for a reason. Ask any of 
them and they will surely point out faults they find in the language 
(Generics being a popular one). But very few who choose to use Java will 
cite performance as a negative for *their purposes*. So to entice a Java 
programmer to come to D, the speed argument just isn't going to fly.

To court Java programmers, you have to convince them that D's features 
are shinier than Java's. You have to show them an advanced tool chain 
that lets them monitor every aspect of an application's performance. 
They want to be able to dynamically instantiate objects via a class name 
string. They want easy use of web services, support for web 
applications, and not to worry about porting issues across different 
platforms.

No matter your opinion of Java, or Walter's, people who use it on a 
regular basis see it in an entirely different light.
Dec 27 2006
parent Sean Kelly <sean f4.ca> writes:
Mike Parker wrote:

 
 So my point is that Java programmers use Java for a reason. Ask any of 
 them and they will surely point out faults they find in the language 
 (Generics being a popular one). But very few who choose to use Java will 
 cite performance as a negative for *their purposes*. So to entice a Java 
 programmer to come to D, the speed argument just isn't going to fly.


Agreed.  Programmers who are really serious about performance over other 
considerations will likely not be using Java, so this isn't a convincing 
argument here.  My personal problem with Java is that I hate the syntax. 
  Although it's fairly similar to C++ and even D, I find the nuances 
that are different to make it tremendously unwieldy.  And the 
deal-breaker is that Generics are complete garbage--I simply refuse to 
go without a decent way to express algorithms in a generic manner after 
having used C++ for so long.


 To court Java programmers, you have to convince them that D's features 
 are shinier than Java's. You have to show them an advanced tool chain 
 that lets them monitor every aspect of an application's performance. 
 They want to be able to dynamically instantiate objects via a class name 
 string. They want easy use of web services, support for web 
 applications, and not to worry about porting issues across different 
 platforms.


If I were to use Java, these would be the reasons.  And I think D has a 
long way to go here.  There is some library work that seems quite 
promising re: dynamic libraries (DDL), and Mango is fairly capable for 
server/web programming, but D is extremely weak in the toolchain 
department.  Windbg may work with D in Win32, but it's complete crap.  I 
have yet to use it without my debug session ending because windbg 
crashed.  The situation is so bad that I've considered developing 
exclusively on Linux in hopes that GDB support is better.  But 
fortunately, the times I want to use a debugger are so few and far 
between that this remains an idle fantasy.  And as for performance, DMD 
has profiling and code coverage tools built-in, which is a huge bonus in 
that regard.


Sean
Dec 27 2006
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Waldemar wrote:

 Actually, the reality is Java is plenty slow in many applications. There is JNI
 for a reason.  Never mind cases where Java is not even considered (fast
servers,
 OS internals, communication, graphics, driveres, embedded, etc, etc.)  As soon
as
 Java reaches C/C++ speed, C++ will disappear.  Not too worry, won't happen any
 time soon.
 
 Having said that, there is always a danger that Sun develops "low level Java"
with
 performance truly matching C++.   If that happens D might as well close the
shop.

 "safer" C/C++ with many custom libs and features.  But you can feel it's just
one
 more step, so watch out.


Last year, I developed a pretty sophisticated machine learning algorithm 
for my company. The training phase of the algorithm needs to read 5 or 6 
gigabytes of data, create incremental indices of commonly occurring 
features in many different categories, conduct a statistical analysis of 
all categorical feature histograms, and then plot each of the indices in 
n-dimensional vector space to create agglomerative category clusters.

There's lots of I/O, and plenty of math involved.

I wrote the code in Java. Thanks to the language's consistent, 
orthogonal semantics, the code is very easy to read and understand. With 
only a little profiling and a few tiny optimization tweaks, I was very 
satisfied with performance.

Then, because this algorithm needed to be deployed to heterogeneous 
environments, a colleague of mine ported my code to C++. He did a 
straight transliteration of the code, preserving the same semantics from 
the Java to C++.

When we timed both implementations, we discovered that mine was 40 
percent faster. Several of the C++ developers on my team were completely 
  incredulous, and they made it their personal quest to optimize the C++ 
version so that it was the performance winner.

They eventually caught up to, and surpassed, the performance of the Java 
code. But only after introducing a bunch of ugly optimizations, making 
the code much more difficult to follow. Of course, the types of 
optimizations that they performed are unavailable in Java.

The moral of the story is that the JVM is fast. Very fast. And 
straightforward implementations of algorithms are often faster in Java 
than in C++. But C++ provides a broader suite of possible 
micro-optimizations, so it's possible to bend over backwards in order to 
write *really* fast code. But, when writing equivalent code in C++ and 
Java, it's tough to say which will have better performance characteristics.

To echo what others have said before me, you will *never* win over any 
Java programmers to D by emphasizing performance.

The lack of a VM requirement, on the other hand, is very compelling.

--benji
Dec 27 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Benji Smith wrote:

 Then, because this algorithm needed to be deployed to heterogeneous 
 environments, a colleague of mine ported my code to C++. He did a 
 straight transliteration of the code, preserving the same semantics from 
 the Java to C++.


What did he do about the memory allocation? Use a gc in C++?
Dec 27 2006
parent Benji Smith <dlanguage benjismith.net> writes:
Walter Bright wrote:

 Benji Smith wrote:

 Then, because this algorithm needed to be deployed to heterogeneous 
 environments, a colleague of mine ported my code to C++. He did a 
 straight transliteration of the code, preserving the same semantics 
 from the Java to C++.


 
 What did he do about the memory allocation? Use a gc in C++?


No, he explicitly deleted all of the objects that he newed.
Dec 27 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Benji Smith wrote:


 
 Then, because this algorithm needed to be deployed to heterogeneous 
 environments, a colleague of mine ported my code to C++. He did a 
 straight transliteration of the code, preserving the same semantics from 
 the Java to C++.


Does that mean that wherever you did "new Foo" he did a "new Foo" also?



 When we timed both implementations, we discovered that mine was 40 
 percent faster. Several of the C++ developers on my team were completely 
  incredulous, and they made it their personal quest to optimize the C++ 
 version so that it was the performance winner.
 
 They eventually caught up to, and surpassed, the performance of the Java 
 code. 


Any idea by how much the C++ surpassed the Java in the end?  Was it 
about the same margin (~40%) or significantly more or less?  It's a big 
difference between 10x the Java performance vs say only 5% faster.


 To echo what others have said before me, you will *never* win over any 
 Java programmers to D by emphasizing performance.


Probably not, if we're talking about someone who has Java Programmer 
with a capital P embossed on their business card.  But I hear that it's 
pretty common these days for schools to teach Java as the main 
programming language to students.  If that's true, then it seems 
reasonable that there is a category of people using Java simply because 
it's what they were taught, and they might be interested in a language 
with syntax not too far from Java which at least in benchmarks 
significantly outperforms java:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=dlang&lang2=java
(and which doesn't require a VM)

--bb
Dec 27 2006
parent reply Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:

 Benji Smith wrote:
 

 Then, because this algorithm needed to be deployed to heterogeneous 
 environments, a colleague of mine ported my code to C++. He did a 
 straight transliteration of the code, preserving the same semantics 
 from the Java to C++.


 
 Does that mean that wherever you did "new Foo" he did a "new Foo" also?


Yes. He also subsequently did a "delete Foo" when he was finished with 
the object.


 When we timed both implementations, we discovered that mine was 40 
 percent faster. Several of the C++ developers on my team were 
 completely  incredulous, and they made it their personal quest to 
 optimize the C++ version so that it was the performance winner.

 They eventually caught up to, and surpassed, the performance of the 
 Java code. 


 
 Any idea by how much the C++ surpassed the Java in the end?  Was it 
 about the same margin (~40%) or significantly more or less?  It's a big 
 difference between 10x the Java performance vs say only 5% faster.


The C++ version eventually outperformed the Java version by 10% ~ 15%.
Dec 27 2006
parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
"Benji Smith" wrote:


 Does that mean that wherever you did "new Foo" [in Java] he did a "new 
 Foo" [in C++] also?


 Yes. He also subsequently did a "delete Foo" when he was finished with the 
 object.


It is no suprise that C++ underperformed, IMO.

/Pavel
Dec 30 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
Waldemar wrote:

 == Quote from Mike Parker (aldacron71 yahoo.com)'s article

 Bill Baxter wrote:

 I wholeheartedly agree with Waldemar, though, that the things that are
 going to sway C/C++ folks are different from what's going to sway


 the other hand, if they find they need to deliver an app that works
 stand-alone, independent of a 100MB runtime environment, or one which
 runs at native speed, then D is probably the closest thing they're going



 Being a long time Java programmer, I strongly disagree with you and
 Waldemar both. Speed is only an issue for people who don't use Java, or
 for those who don't really know how to properly write software with it.
 Most Java programmers I know, myself included, call the "Java is slow"
 mantra a myth. Java *used to* be slow, true. Today, it's possible to
 code a clunky app in Java if you don't know what you are doing. But the
 reality is that it's plenty fast in the general case. Plus, Java


 
 Actually, the reality is Java is plenty slow in many applications. There is JNI
 for a reason.  Never mind cases where Java is not even considered (fast
servers,
 OS internals, communication, graphics, driveres, embedded, etc, etc.)  As soon
as
 Java reaches C/C++ speed, C++ will disappear.  Not too worry, won't happen any
 time soon.
 
 Having said that, there is always a danger that Sun develops "low level Java"
with
 performance truly matching C++.   If that happens D might as well close the
shop.

 "safer" C/C++ with many custom libs and features.  But you can feel it's just
one
 more step, so watch out.
 


D is a great all-around language, but in order to get the benefits of a
language like D ("low level 
Java"), you have to trade some safety and 'hand-holding'. The typical Sun and
MS customer is not 
interested in paying Sun or MS for Java / .NET tools and support only to turn
around and have to pay 
for tools / support for another 'lower level' language with a 'buggy' (because
it's newer) port of 
the same library written for a native compiler.

I seriously doubt Sun or MS would invest in something like that when the market
has been moving the 
other way for so long. For one thing there's the bottom line -- Sun makes it's
profit from hardware 
and services [like tuning Java applications] and MS makes much of it's profit
from new licenses for 
bloated software sold to run on newer, ever faster hardware.

Neither would really stand to 'profit' from an easy to use, high performance,
natively compiled 
language when there's C/++ for those jobs already. MS has recently went to
great expense to 
"retrofit" C++ for .NET, not the other way around. For a large company to
produce a new language, go 
through the growing pains of developing a new language like D, and then
retrofit the Java or .NET 
libs. to take advantage of the new language would be an enormous cost. Even
with a huge amount of 


I forget the name of it, but Sun came up with a language / runtime intended for
numerics. It is 
anything but small, lightweight and single-CPU efficient. It looked like more
of a resource pig than 
even Hotspot. It's purpose was really to sell Sun hardware and services, no
doubt.

I see it more likely that once D takes off, MS, Sun and others may then develop
their own 
compilers/runtimes/libs. for D because they need the bundle to make their
systems and tools the most 
appealing to a wide range of customers.
Dec 27 2006
prev sibling parent reply renoX <renosky free.fr> writes:
Mike Parker a écrit :

 Being a long time Java programmer, I strongly disagree with you and 
 Waldemar both. Speed is only an issue for people who don't use Java, or 
 for those who don't really know how to properly write software with it.


Note that the "people who don't know to write software" include even 
Sun: in Solaris9, Sun rewrote the administration tools in Java, the result?
Well, the tools were so slow, that I learned to use the command-line 
tools instead of the GUI, because they were so damn slow that each time 
I used these tool, I was really pissed-off by the slowness..

It's probably possible to write fast Java apps, but even Sun don't 
manage to do it, and all the Java apps I've used have annoyed me by 
being too slow, so it's definitely not trivial: I think that using D 
it's easier to get fast apps.

Regards,
renoX

PS: Of course with D, there is the library problem..
I'd really like to have a wrapper of Qt in D..
Dec 27 2006
parent Sean Kelly <sean f4.ca> writes:
renoX wrote:

 Mike Parker a écrit :

 Being a long time Java programmer, I strongly disagree with you and 
 Waldemar both. Speed is only an issue for people who don't use Java, 
 or for those who don't really know how to properly write software with 
 it.


 
 Note that the "people who don't know to write software" include even 
 Sun: in Solaris9, Sun rewrote the administration tools in Java, the result?
 Well, the tools were so slow, that I learned to use the command-line 
 tools instead of the GUI, because they were so damn slow that each time 
 I used these tool, I was really pissed-off by the slowness..


The new Sun debugger (SunStudio) is the same way.  It has a lot of nice 
features, but is so slow I end up doing most of my debugging in emacs 
with dbx.  One of these days I'll take the time to turn off the bits 
that are killing performance and give it another try.


Sean
Dec 27 2006
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?


If "you shouldn't rely too much on that" means my arguments should be 
independent of the newcomer's background, then I give up.

Suppose you're a used-car salesman and you have this better-than-average 
car to sell. Now, find an argument that works equally well for customers 
like a redneck, a computer whiz kid, a plumber, a pimp, a family mother, 
a student, and a grandma.

It's a waste of gunpowder to try to conjure up a universal argument.

---

To somebody without a prior language, I'd say don't, because there 
aren't any good books out yet.


To a university I'd say: (I've spent 5 years teaching programming in a 
university)

This is the language you've been waiting for ever since Pascal went out 
the door. With this language you can teach both the standard C-family 
imperative programming concepts, as well as an exceptional selection of 
the more modern concepts.

The language is both clear enough to be used as a first language, and 
powerful and real-world usable enough to be used for post graduate work, 
as well as for professional programming. As such it offers an excellent 
"mother tongue" from which forays into other Algol family languages as 
well as non-Algol family ones can be made with a minimum of friction.

It can also be argued that if a student ultimately needs to be fluent in 
C++, he should take programming intro in D, intermediate in D, and only 
then jump (directly) to advanced C++. Since most of the concepts are 
common between these languages, the student saves much time and gains a 
more solid understanding of those concepts with D, where most of his 
attention doesn't go to ambiguities, exceptions, caveats, or the 
compiler drowning him or sending him of to wild goose chases in the night.


To a C/C++ programmer I'd say:

Automatic memory management in a compiled language, you don't know what 
you're missing until you actually try it out! Compile a 5 minute 
compilation in 15 seconds! What if you could skip using lint altogether? 
How about never again needing to spend hours explaining to the younger 
colleagues all about pointer dereferencing and double indirection? 
Learning curve for C/C++ users: next to nothing!!


To a C++ guru:

Check out the metaprogramming stuff, and what folks have done with it! 
Double your productivity, honest! And the extra bonus: when's the last 
time you actually enjoyed programming?




Run without the VM!!!!! And get access to the metal, be in real control 
of the computer!! And you haven't seen this kind of speed since the 
barrio pushers got busted!


To a code shop boss:

Bounds checking, pre- and post-conditions, unit tests, no header files! 
And syntax is straightforward enough that you actually can write your 
own tools for analysis, manipulation, rules enforcement, and code 
generation! And finally: you won't believe the increase in overall 
productivity!
Dec 26 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?


It really depends on what features I think that specific person would be 
interested in, but those I'd mention to everyone are: inner functions 
and delegates.  Interestingly, I completely forgot about variable-length 
arrays and associative arrays, and I think this is because they are such 
fundamental features of the language.  So add those to the list as well :-)


Sean
Dec 26 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?
 
 Andrei


I wouldn't introduce feature X or Y, because they can always find 
another language with that feature, or even with a better feature.

I would talk about the reason D was developed and how it saves you a lot 
of time.
Dec 26 2006
prev sibling next sibling parent Clay Smith <clayasaurus gmai.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?
 
 Andrei


static if/templates

module system

built in string/dynamic array/associative array/bounds check

compile time

not on a VM

new features incorporated very quickly, and no committee to govern what 
goes in

can call C code
Dec 26 2006
prev sibling next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu's article

 Say you wanted to introduce a programmer friend to D. She might know one

 too much on that. What features of D would you describe first to hook
 that friend in?

 Andrei


I've tried introducing D to people, and response varies.  For people that see
C++ as having no advantages over C, it's probably an impossible sell.  For
people that like C++ but have been working with it long enough to be annoyed at
the syntax, the cleaner syntax (especially for template metaprogramming) have
made an impression.

The real selling point for me is that it has basically all of the safety and
simplicity of use of something like Java, but does not have the handcuff and
straight jacket feeling.  The "we are all in this boat and we will all follow
the rules" approach of Java, along with some of the more arbitrary missing
features (i.e. unsigned types) causes the language to drag when working with
high-performance and high-requirement (i.e. number crunching and hardware
oriented) fields.

The starting point I use is that it has almost all the features and power of
Java and C++ but is cleaner and more usable than Java.  If they are still
interested I point them here (http://www.digitalmars.com/d/comparison.html),
since I think it's a good jumping off point for a C++ or Java programmer.

There was something about a web server that doesn't need to allocate
memory to process requests - I can't find a link for this, but I use
it to describe the power of array slicing.

I think these are the most impressive "Why D" type pages:

http://www.digitalmars.com/d/comparison.html
http://www.digitalmars.com/d/lisp-java-d.html (esp. if they know lisp)
http://www.digitalmars.com/d/templates-revisited.html
http://www.digitalmars.com/d/overview.html

And if they don't know anything about GC:

http://www.digitalmars.com/d/garbage.html

For C++, the formula is, find out what they are working on, and show how
it can be done much more simply in D.  If they are Java programmers, find
out what they are working on, and show how much faster it is in D.

Kevin
Dec 26 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?


For me, it's hard to pinpoint any particular feature or two. It's the 
combination of features that makes the cake, not the sugar, flour or 
baking powder. So,

1) My programs come together faster and have fewer bugs.
2) Once written, the programs are easier to modify.
3) I can do (1) and (2) without giving up performance.
Dec 26 2006
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Walter Bright wrote:

 
 For me, it's hard to pinpoint any particular feature or two. It's the 
 combination of features that makes the cake, not the sugar, flour or 
 baking powder. So,
 


This is the line I take. I do harp on D's arrays (which I love), but the 
real benefit comes from all of the little bits coming together to make 
the whole. As an example in miniature (and since people love specifics), 
static if, static foreach, tuples, and other little features all come 
together to make D's templates much more powerful and flexible than 
those of C++, or Java's crappy Generics.
Dec 27 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 
 1) My programs come together faster and have fewer bugs.
 2) Once written, the programs are easier to modify.
 3) I can do (1) and (2) without giving up performance.


Pretty succinctly put!

Maybe this could be on the website somewhere?
Dec 27 2006
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?
 
 Andrei


I might ask her out for dinner, so that I could describe many of D's 
cool features. ^^

Seriously now, to hook a friend in, it would depend on the friend: its 
background, the languages the friend knows and likes, etc. . What I can 
say is that what has drawn me to D in the first place was that D is a 
speed language without the obnoxiously obsolete C++ crap: structured 
module system instead of #includes&headers files, no need for function 
prototypes before use, methods are defined inside the aggregates, basic 
types with well defined sizes (no more SDL's UInt8, UInt16, etc., or 
OpenGL's GLint, GLfloat, etc.), uniform declarations (like the non-C 
array declaration syntax, or struct declaration in the same namespace as 
everything else), overall cleaner syntax, etc. . The advanced features 
(dyn-arrays, GC, D's templates,etc.) are also very nice, but for me the 
most important was really getting the basics right.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 27 2006
prev sibling next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?


When D comes up in conversation, I usually bring up the following points 
in order:


- *No VM or Interpreter*
- Garbage-Collected
- Portable
- Built-in Array types (No need for STL)
- Template features that mop the floor with Java and .NET.
- Type Inference (auto)
- Relatively open front-end, core library and GC.

The rest is really just icing on the cake.

-- 
- EricAnderton at yahoo
Dec 27 2006
prev sibling next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
In order of importance (best first):
* Built-in arrays/slices
* The scope(..) construct
* everything 'public' within one module

L.
Dec 27 2006
prev sibling next sibling parent reply BCS <BCS pathilink.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?
 
 Andrei


Mostly it is the fact that a programing can be made more reliable and 
maintainable.

Simple consistent syntax is one part of this. The "It's easy to program 
in" also is part.

My favorite thing right now is this: Things can be made "intent-ional" 
(think "funct-ional") sort of a #define on steroids. This comes from use 
of const and templates. The after doing things like parser generation 
and ASM-stype bignum with template code I could actually stand reading 
really makes me think there is something here. After showing the 
template parser generator to a prof of mine, he said "Quit tempting me" 
to start learning D, this from a guy that likes Prolog (nothing wrong 
with that BTW).






p.s. & OT: that might as well be the abstract for the current version of 
my, "intro to D: why it will take over the world some day" paper:

http://www.uidaho.edu/~shro8822/term_009.pdf

comments welcome.
Dec 27 2006
parent BCS <BCS pathilink.com> writes:
 p.s. & OT: that might as well be the abstract for the current version of 
 my, "intro to D: why it will take over the world some day" paper:
 
 http://www.uidaho.edu/~shro8822/term_009.pdf
 
 comments welcome.



BTW: that version is the current version that I had when I noticed that 
it might have some bearing on the topic. I'm sure spelling and grammar 
errors abound, so please ignore them.
Dec 27 2006
prev sibling next sibling parent Serg Kovrov <kovrov no.spam> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?


Those mostly for c/c++ guys:
- builtin arrays (with bound-checks inserted by compiler)
- array slicing
- delegates
- lambdas
- RAII
- DBC
- stdlib and compiler-generted code uses exceptions
- string switches
- modules
- foreach
- can use c-libs
- can provide c-interface

And for java/.net folks:
- native code (as opposite to VM)

-- 
serg.
Dec 28 2006
prev sibling next sibling parent reply torhu <x x.xxx> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?
 


D is the compiled language I know that comes closest to python.  Hearing 
that would make me interested, I can tell you.
Dec 29 2006
parent reply Brad Anderson <brad dsource.org> writes:
torhu wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know

 rely too much on that. What features of D would you describe first to
 hook that friend in?


 
 D is the compiled language I know that comes closest to python.  Hearing
 that would make me interested, I can tell you.


That's a very good point.  I agree that it's the closest to Python (albeit,
"as close as a lang like this can go", and I agree that this will be an
interesting statement to a fairly wide audience.  If we could only get some
docs like Python, to complement the reference at DigitalMars...

BA
Dec 29 2006
parent reply Jeff <jeff jeffrules.com> writes:
On 2006-12-29 15:12:41 -0800, Brad Anderson <brad dsource.org> said:


 torhu wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know

 rely too much on that. What features of D would you describe first to
 hook that friend in?
 


 
 D is the compiled language I know that comes closest to python.  Hearing
 that would make me interested, I can tell you.


 
 That's a very good point.  I agree that it's the closest to Python (albeit,
 "as close as a lang like this can go", and I agree that this will be an
 interesting statement to a fairly wide audience.  If we could only get some
 docs like Python, to complement the reference at DigitalMars...
 
 BA


I am not very impressed by Python's docs.  The best docs that I've seen 
are the PHP docs because of commenting and excellent examples.

-- Jeff
Dec 30 2006
next sibling parent reply Serg Kovrov <kovrov no.spam> writes:
Jeff wrote:

 I am not very impressed by Python's docs.  The best docs that I've seen 
 are the PHP docs because of commenting and excellent examples.


Second that.

PHP docs are well organized. Personally, I find it extremely intuitive. 
As far as I remember, it takes near no time to find what I want without 
knowing exact names or using search.

Contrarily, Python docs are plain hell to work with.

-- 
serg.
Dec 30 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Serg Kovrov wrote:

 Jeff wrote:

 I am not very impressed by Python's docs.  The best docs that I've 
 seen are the PHP docs because of commenting and excellent examples.


 
 Second that.
 
 PHP docs are well organized. Personally, I find it extremely intuitive. 
 As far as I remember, it takes near no time to find what I want without 
 knowing exact names or using search.
 
 Contrarily, Python docs are plain hell to work with.
 


I cannot count the number of times I've filled up a full instance of Firefox
with a dozen 
tabs or so, all open to PHP doc files.  It is indeed intuitive.  (And the
comments are 
often just as useful as the docs themselves!  For example: PHP has no
is_assoc() to go 
along with is_array()... but look at the comments for the docs on is_array()
and you can 
find a few examples of is_assoc() implementations right there.)

I'd be quite jolly to see a similar approach to the D docs, along with the "as
of version 
X" descriptors, etc.

-- Chris Nicholson-Sauls
Dec 30 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Chris Nicholson-Sauls wrote:

 Serg Kovrov wrote:

 Jeff wrote:


 I am not very impressed by Python's docs.  The best docs that I've 
 seen are the PHP docs because of commenting and excellent examples.


 Second that.

 PHP docs are well organized. Personally, I find it extremely 
 intuitive. As far as I remember, it takes near no time to find what I 
 want without knowing exact names or using search.

 Contrarily, Python docs are plain hell to work with.


 I cannot count the number of times I've filled up a full instance of 
 Firefox with a dozen tabs or so, all open to PHP doc files.  It is 
 indeed intuitive.  (And the comments are often just as useful as the 
 docs themselves!  For example: PHP has no is_assoc() to go along with 
 is_array()... but look at the comments for the docs on is_array() and 
 you can find a few examples of is_assoc() implementations right there.)
 
 I'd be quite jolly to see a similar approach to the D docs, along with 
 the "as of version X" descriptors, etc.


Picture this: two guys, each with their own web site, compete on world 
dominance on D documentation customer satisfaction. One is an absolute D 
guru and an average PHP programmer, the other is an absolute PHP guru 
and an average D programmer. Who'd you bet on? My bet's on the latter.

It's the infra that counts. But I'll come back to this once I've sobered 
up from the D 1.0 champagne which I'll drink to instead of the New Year. 
Too bad my local store doesn't carry Bollinger. ;-)
Dec 30 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Georg Wrede wrote:

 Chris Nicholson-Sauls wrote:

 Serg Kovrov wrote:

 Jeff wrote:


 I am not very impressed by Python's docs.  The best docs that I've 
 seen are the PHP docs because of commenting and excellent examples.


 Second that.

 PHP docs are well organized. Personally, I find it extremely 
 intuitive. As far as I remember, it takes near no time to find what I 
 want without knowing exact names or using search.

 Contrarily, Python docs are plain hell to work with.


 I cannot count the number of times I've filled up a full instance of 
 Firefox with a dozen tabs or so, all open to PHP doc files.  It is 
 indeed intuitive.  (And the comments are often just as useful as the 
 docs themselves!  For example: PHP has no is_assoc() to go along with 
 is_array()... but look at the comments for the docs on is_array() and 
 you can find a few examples of is_assoc() implementations right there.)

 I'd be quite jolly to see a similar approach to the D docs, along with 
 the "as of version X" descriptors, etc.


 
 Picture this: two guys, each with their own web site, compete on world 
 dominance on D documentation customer satisfaction. One is an absolute D 
 guru and an average PHP programmer, the other is an absolute PHP guru 
 and an average D programmer. Who'd you bet on? My bet's on the latter.
 
 It's the infra that counts. But I'll come back to this once I've sobered 
 up from the D 1.0 champagne which I'll drink to instead of the New Year. 
 Too bad my local store doesn't carry Bollinger. ;-)


I went out and bought some Barenjager and Chartreuse for the occasion, myself.

-- Chris Nicholson-Sauls
Dec 30 2006
prev sibling next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Jeff wrote:

 On 2006-12-29 15:12:41 -0800, Brad Anderson <brad dsource.org> said:
 
 I am not very impressed by Python's docs.  The best docs that I've seen 
 are the PHP docs because of commenting and excellent examples.
 
 -- Jeff
 


I agree with this %300.

What I find most humorous about PHP is that it *needs* good 
documentation because the "API" is so horribly fragmented - they kept 
the import names and call signatures from all those C libs, rather than 
normalize them.  The doc-comments feature was also a must-have since the 
documentation provided was (and in places, still is) anything but 
adequate on it's own.

The only major fault in the PHP doc web is that the documentation isn't 
ever really updated *from* the user provided comments.  You'd think an 
editor would gather up all the corrections and examples and fold them 
in, rather than let them hang out there for years on end?  I've seen 
some threads where the oldest posts are mis-information of the worst 
kind due to them dating back to PHP 3.0.

Another example: the ColdFusion docs do have editors that upgrade/update 
the system regularly.  However, they like to wipe out *everything* 
between language versions on their website - they're separate webs after 
all.  The result is the CF5, CFMX6 and CFMX7 doc webs all have different 
user content.

-- 
- EricAnderton at yahoo
Jan 03 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Jeff wrote:

 I am not very impressed by Python's docs.  The best docs that I've seen 
 are the PHP docs because of commenting and excellent examples.


The user comment thing is very good. That's why all the D documentation 
pages have a wiki comment link in them.
Jan 03 2007
parent Tim Keating <holyspamster gmail.com> writes:
In article <enh2t0$15pk$1 digitaldaemon.com>, newshound digitalmars.com 
says...

 The user comment thing is very good. That's why all the D documentation 
 pages have a wiki comment link in them.


Huh. I've been using those docs for months, and I never even noticed 
those buttons up there. That's pretty cool.

TK
Jan 11 2007
prev sibling parent janderson <askme me.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Say you wanted to introduce a programmer friend to D. She might know one 

 too much on that. What features of D would you describe first to hook 
 that friend in?
 
 Andrei



frustrated with the arrays.  They are not standardized.  There seems to 
be about 10 different ways to specifying arrays (note that I'm including 
net).

Some use count and others use length.  Some are fixed size and others 
arn't.  Some can be allocated at a particular size on the fly but then 
you can't change it without creating a brand new array.  It took my an 
hour to work out how to convert an ArrayList to an ViewItem[] list 
because it uses a completely un-logical mechanism.

Also most net classes still haven't adopted templates so your left with 
these horrible un-typesafe objects which you can only figure out at run 
time (if your lucky).  Granted D doesn't even have anything like net, 
but I doubt it will be anywhere near as bad with standardized arrays.

std in C++ is better but u still get the same problem as many libs what 
to implement there own type.

-Joel
Jan 04 2007