>> If game developers are to move to a different language than C++, this has to be better, not the same.

As someone who has spent a lot of time using C++, I'm attracted
to D in part because I have a laundry list in my head of things that
I'd like fixed in C++ and D currently fixes a good percentage of those
and only backtracks in a few areas.  There's just no way D would have been
developed in its current shape by people who hadn't spent a lot of time
with C++ (though I wonder why so little love for const-correctness -
seems like an odd preference combo to add exception safety and lose this).
A lot of the improvements however are difficult to emphasize to casual or
non-developers.

Intuitively I think that a compile time option to only accept provably memory-safe code would likely be a killer feature to drive C++ developer adoption, though it might take a lot of work to get the compiler and mainstream library practice smart enough to make it usable.

Lars Ivar Igesund wrote:
> clayasaurus wrote:
>>Sweeney has expressed interest in a new language so I don't think it
>>would be too far fetched. No harm in trying, at least.

Let's hope he's unconsciously talking about D! :-)

> Do the search "sweeney site:digitalmars.com" at Google, and you'll find many
> posts from him in the oooooold D newsgroup, about 5 years ago.

The first thing I stumbled upon was a thread called Persistance (sic).

> Fri, 17 Aug 2001 21:33:01 -0400 "Tim Sweeney" <tim xx epicgames.com>  writes:
> If a language has complete support for introspection (discovering all fields
> of objects at runtime), then it's easy for users to implement arbitrary
> persistence algorithms, such as XML or various binary formats. So a desire
> for persistence can be simplified into a more general desire for complete
> (perhaps Java-style) introspection support.
> 
> -Tim

And later in the thread:

> Fri, 9 Nov 2001 21:12:31 -0800 "Walter" <walter xx digitalmars.com>  writes:
> I intend for D to support introspection. It makes garbage collection more
> effective, as well as making persistance possible. It also makes it easier
> for debuggers <g>.

Lars Ivar Igesund wrote:
> Do the search "sweeney site:digitalmars.com" at Google, and you'll find many
> posts from him in the oooooold D newsgroup, about 5 years ago.

This is the second. The man seems to know what he's talking about. A shame I forget what the rationale for eroding the difference between member and member function access in D?

> Fri, 17 Aug 2001 21:55:37 -0400 "Tim Sweeney" <tim xx epicgames.com>  writes:
>> Thu, 16 Aug 2001 20:06:56 +0200 "Sheldon Simms" <sheldon xx
>> semanticedge.com>
>> In D, get'ers and set'ers take advantage of the idea that an lvalue
>> is a set'er, and an rvalue is a get'er:
>>
>> class Abc
>> {
>> int myprop;
>> void property(int newproperty) { myprop = newproperty; } // set'er
>> int property() { return myprop; } // get'er
>> }
>>
>> which is used as:
>>
>> Abc a;
>> a.property = 3; // equivalent to a.property(3)
>> int x = a.property; // equivalent to int x = a.property()
> 
> Why??!? :-) In current reasonable languages "a.x" is a variable access and
> "a.f(x)" is a function call.
> 
> Why complicate this so that "a.x" could either be a function call or a
> variable access, depending on its (possibly very complicated) context?
> 
> Also, this seems to create ambiguity (or context-specific special-casing of
> sematics) with function pointers. Given a reference to a function p taking
> a parameter, p=a could either mean calling it with a parameter of a, or
> initializing it to a.
> 
> I know Bertrand Meyer advocated this approach in Eiffel, but this has been
> shown to be one of several areas (along with, i.e. covariant typing on
> function parameters) where Eiffel's type system is unsafe and problematic.
> 
>> Thus, in D you can treat a property like it was a simple field name.
>> A property can start out actually being a simple field name, but if
>> later if becomes necessary to make getting and setting it function
>> calls, no code needs to be modified other than the class definition.
> 
> That breaks with open-world modules. For example, given a module declaring
> a class like:
> 
> class c
> {
> int a;
> };
> 
> How can you subclass it later on in another module like:
> 
> class d: public c
> {
> int a() {...}
> };
> 
> The similar question comes up with binary-compatible evolution of modules
> (i.e. Java's list of rules, "You can do the following things to evolve a
> class without breaking existing precompiled modules that depend on it".
> That's an essential thing that's vital to writing real-world programs, such
> as applications supporting plug-ins. The only sound solution to this is
> that every variable access in a program has to translate to a virtual
> function call, which obviously isn't reasonable.
> 
> -Tim
> 

Georg Wrede wrote:
> Walter Bright wrote:
>>> Many of these features are new to the entire extended language family, or have been implemented in radically different ways than previously in the extended language family. Are mixins going to cause a problem with lambdas? Is liberal use of slices going to make DBC unmaintainable? Who knows! Who's going to find out? The early adopters.
>>
>> On the one hand, that is a valid concern. Many of the bug reports are coming from unexpected interactions between features. 
> 
> Ouch. But as long as they are fixable, and especially as long as they are not theoretically impossible to fix, I guess we're in business. ;-)

They almost always turn out to be fixable, one way or another.

>> What can be done with the combination of all those capabilities has
>> yet to be fully explored.
> Some template judo we've seen is simply impressive, and if we get more guys like that here who'd become interested in the other aspects, we really might see something interesting.

I'm amazed at what smart people have done with D and C++.

>> But on the other hand, I don't think this is a reason to be hesitant to use D. If those more unusual combinations cause a problem, just don't use them that way. It isn't necessary to remove the features from the language!
> 
> The C++ guys certainly shouldn't complain, they already do it every day.
> 
> And not using the entire feature set in each source file might be a good idea with any language. :-)

It's certainly been a good idea for C++ for decades.

Georg Wrede wrote:
> This is the second. The man seems to know what he's talking about. A shame I forget what the rationale for eroding the difference between member and member function access in D?

Now I start to understand what the guy at gamedev may have meant. Originally I wanted to disagree:

> And D goes so, so much further. The designers have a "why not"
> attitude towards adding useful-sounding features



---

Sorry for replying to myself: I goofed and pressed send before inserting in the previous post.

J Duncan wrote:
> Excellent thread! Ive said before that D *SHOULD* be the future of game development, and for some smart people it will be. Ive worked on several commercial game projects and it occurs to me that a large bulk of our engines were basically macros, templates, and patterns to implement many of the idioms D currently contains (and sometimes java); basically, to transform C++ into a 'better' language.

In big projects I've done in C++, a large part of the effort was doing infrastructure things, things that are built in to D. How many times have I done and redone and redone string classes, file handling, collections, symbol tables, etc.

> And we still use C++ almost exclusively for performance reasons. This is why D should fill this space quite well. I tend to have a more laid back approach to all of this however, I believe we have a lot of work to do regarding the language infrastructure, and once that is in place the popularity will take care of itself. Build it and they will come.

Yes.

> Also I noticed one of the things sweeny mentioned in the DNG was persistent objects.... something we may be heading towards with DDL. So the future is pretty bright and I feel that once we have some of these world class features like reflection etc, many people will take a serious look at D. And on that note ive noticed some people will probably *never* be convinced that a language is better for them than c++, this has something to do with human nature that I dont fully understand. This is a big reason I stopped worrying about D popularity.

A large fraction of current C++ developers will never leave C++, no matter what. Just like there are still people who never moved past C. They'll always search for, and will find, some niche reason why C++ is better no matter what advantages D has. That's just a fact of human nature, and shouldn't bother us.

> also as a big fan of QT, Id like to request a S&S mechanism; or some sort of messaging pattern in the language. I think this would take D "over the top!"

While I appreciate and enjoy the enthusiasm, this is deja vu all over again. My entire career in compilers (C, C++, D, Javascript, etc.) I've heard people say that "if only you implemented X, it will open the floodgates!" It never does, but what does work is to work with people who are *already* D users who are blocked by the lack of something. With S&S, I'd like to see first how far it can be pushed with existing D techniques.

Georg Wrede wrote:
> Or, could it be that D actually is bigger than C++ _feature_wise_, while C++ is _much_ larger than D when we look at the ramifications of their respective feature sets.

D *is* bigger feature wise. But complexity wise, C++ beats it. The trouble with C++ is that its features are not very orthogonal - and where they interact/conflict there are a lot of weird special case rules. I have recently exchanged yet another set of emails with a person who is a top C++ expert who insisted that DMC++ had a serious bug with template name lookups. Turns out that DMC++ actually was implementing the name lookup rules *according to the C++ standard* and the other compilers were not. The bottom line is even the experts don't know how it is supposed to work.

Another example is the preprocessor. It took 10+ years for C/C++ compiler vendors to implement it correctly. This isn't because doing a macro processor is inherently difficult, it is because the specification for C's macro language is so obtuse and full of bizarre special cases. I know I've spent countless hours trying to figure out (1) how it's supposed to work and (2) how to implement it. It's been scrapped and totally reimplemented about 4 times.


> What I mean is, one could write a "complete" book about D, and it still would be just a fraction of the size of Stroustrup's "C++". And that's because most of his book explains and chews on issues and implications that are unobvious to the reader or programmer, and that demand knowing them lest you shoot yourself in the foot -- and not even later understand what happened.
> 
> D has virtually no such crap, so we can scrap 500 pages right off the bat.

Consider just one issue with C++ - how to write a "correct" iterator class. Even harder is writing a "correct" container class.

Georg Wrede wrote:
> The key here is _focus_. I's all the more important at a stage where the  number and depth of our libraries is small, general documentation is next to nothing, and the little we do have in documentation way is... (Not that I'd start throwing rocks in a glass house, I've been asked to help with documentation, and I've yet to pick that up. But I aim to.)

What I'd like to see and think would be the most valuable, is a greater presence on the web for D. This means creating web sites about D, bringing up D in blogs where appropriate (spamming for D in inappropriate blogs would be a bad idea), etc. By improving the web presence, programmers will notice that there is a large and active D community, and so will feel a lot more comfortable trying it out and helping it out.

And then the rest will follow.

Walter Bright wrote:
> J Duncan wrote:
>> Excellent thread! Ive said before that D *SHOULD* be the future of game development, and for some smart people it will be. Ive worked on several commercial game projects and it occurs to me that a large bulk of our engines were basically macros, templates, and patterns to implement many of the idioms D currently contains (and sometimes java); basically, to transform C++ into a 'better' language.
> 
> In big projects I've done in C++, a large part of the effort was doing infrastructure things, things that are built in to D. How many times have I done and redone and redone string classes, file handling, collections, symbol tables, etc.
> 
>> And we still use C++ almost exclusively for performance reasons. This is why D should fill this space quite well. I tend to have a more laid back approach to all of this however, I believe we have a lot of work to do regarding the language infrastructure, and once that is in place the popularity will take care of itself. Build it and they will come.
> 
> Yes.
> 
>> Also I noticed one of the things sweeny mentioned in the DNG was persistent objects.... something we may be heading towards with DDL. So the future is pretty bright and I feel that once we have some of these world class features like reflection etc, many people will take a serious look at D. And on that note ive noticed some people will probably *never* be convinced that a language is better for them than c++, this has something to do with human nature that I dont fully understand. This is a big reason I stopped worrying about D popularity.
> 
> A large fraction of current C++ developers will never leave C++, no matter what. Just like there are still people who never moved past C. They'll always search for, and will find, some niche reason why C++ is better no matter what advantages D has. That's just a fact of human nature, and shouldn't bother us.
> 
>> also as a big fan of QT, Id like to request a S&S mechanism; or some sort of messaging pattern in the language. I think this would take D "over the top!"
> 
> While I appreciate and enjoy the enthusiasm, this is deja vu all over again. My entire career in compilers (C, C++, D, Javascript, etc.) I've heard people say that "if only you implemented X, it will open the floodgates!" It never does, but what does work is to work with people who are *already* D users who are blocked by the lack of something. With S&S, I'd like to see first how far it can be pushed with existing D techniques.

This last paragraph is why D will succeed. Walter, if this isn't the best way to evolve a language, I don't know what is.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

Walter Bright wrote:
> 
> Even harder is writing a "correct" container class.

Darn straight.  C++ allocator requirements make things pretty messy, and complying to exception guarantee requirements with data types that may throw when copied is just a mess.  I'm very glad that D doesn't have this level of complexity.


Sean