Andrei Alexandrescu (See Website For Email) wrote:
> Say you wanted to introduce a programmer friend to D. She might know one of D's sibling languages (Java, C, C++, or C#), but you shouldn't rely 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.

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 Java/C# folks.  D's library and development tools are still rather anemic, so most likely that would send most Java/C# folks running.  On 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 to find to their beloved Java/C# that can do the job.
> 

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

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.

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

== 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 Java/C# folks.  D's library and development tools are still rather anemic, so most likely that would send most Java/C# folks running.  On 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 to find to their beloved Java/C# that can do the job.
> >
> 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.
 Same thing with C#.  MS can definitely do it.  At the moment they go with this
"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).

Andrei Alexandrescu (See Website For Email) wrote:
> Say you wanted to introduce a programmer friend to D. She might know one of D's sibling languages (Java, C, C++, or C#), but you shouldn't rely 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

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?

Andrei Alexandrescu (See Website For Email) wrote:
> Say you wanted to introduce a programmer friend to D. She might know one of D's sibling languages (Java, C, C++, or C#), but you shouldn't rely 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:

- Java/C# like syntax
- *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

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
> might as well close the shop. Same thing with C#.

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?

In order of importance (best first):
* Built-in arrays/slices
* The scope(..) construct
* everything 'public' within one module

L.