Seems to me that while D is marketed as a Systems development language, it will be quite some time before anybody has developed a System with D.

More plausible should be that one day games developers will find D /en masse/ because everything in D really is perfect for games development. We already have astonishing power of expression, an integrated GC (while it may at the outset look like it discourages games development, serious game shops should have no problem in discovering that you can either disable the gc for critical sequences, pool staple instances, or just new and delete (in essence, "touch") in advance the expected amount of memory), very easy integration of scripting languages (DMD-Script, Lua, Python), in-built associative structures, direct access to C-code libraries and system functions (while touted as trivial to use from D, they at least aren't impossibly cumbersome in practice), and in-built UTF-8 all the way.

And, I've heard some games developers state, they'd "rather lose 10% in game speed if they can win 10% in developer costs". I'm sure all here agree D can deliver at least this 10% slash in developer costs, while possibly even making the binary /faster/ than with e.g. C++, hands down!

The games industry is something we can expect to become one of the absolutely most important areas of code development in the near future, both in lines of code and in reaped revenue. Being a successful language in that single area would give D success beyond conservative dreams.

The one thing that could really set D apart from other languages would be a siglnals/slots mechanism that was incorporated as an _integral_ part of {the syntax | the core | Phobos} of D.

That something happens in a game that has bearing on potentially a lot of objects or individuals in the game, is simply key in games development. Having to manually code all this is ridiculous at a time when there exist established and well understood mechanisms for it.

---

Recently I had to write a command interpreter for a (in itself trivial) control language for a materials production process control program. The ease and joy of development was largely due to the std.regexp library. It was simply exhilarating.

If we could offer the game developers a smooth and transparent method for passing messages instead of a cumbersome design pattern, I think many shops would look upon us with a new eye.

In my humble opinion, the reason why QT is an absolute winner in the industry is simply because the signals/slot paradigm is central to that library. That in itself creates a sensation of robustness, quality, and a kind of completeness. The ease of utilizing it has most probably made the overall quality of the rest of the library much higher, by letting their programmers concentrate on the issues at hand instead of fighting with the trivialities of message passing.

We have to remember that interactive "real time" games development is the one area where signals (or messages) are an essential part of every major application. Both in the user interface and in the games engine logic itself.

---

We only have to become the _preferred_ language in _one_ area! After that it'll automatically follow that we gain other areas and a huge general interest. ("If C is good enough for Unix itself, it has to be a good language. -- If D is good enouhg for some of the best games shops, it has to be a good language.")

Georg Wrede wrote:
> Seems to me that while D is marketed as a Systems development language, it will be quite some time before anybody has developed a System with D.
> 
> More plausible should be that one day games developers will find D /en masse/ because everything in D really is perfect for games development. We already have astonishing power of expression, an integrated GC (while it may at the outset look like it discourages games development, serious game shops should have no problem in discovering that you can either disable the gc for critical sequences, pool staple instances, or just new and delete (in essence, "touch") in advance the expected amount of memory), very easy integration of scripting languages (DMD-Script, Lua, Python), in-built associative structures, direct access to C-code libraries and system functions (while touted as trivial to use from D, they at least aren't impossibly cumbersome in practice), and in-built UTF-8 all the way.
> 
> And, I've heard some games developers state, they'd "rather lose 10% in game speed if they can win 10% in developer costs". I'm sure all here agree D can deliver at least this 10% slash in developer costs, while possibly even making the binary /faster/ than with e.g. C++, hands down!
> 
> The games industry is something we can expect to become one of the absolutely most important areas of code development in the near future, both in lines of code and in reaped revenue. Being a successful language in that single area would give D success beyond conservative dreams.
> 
> The one thing that could really set D apart from other languages would be a siglnals/slots mechanism that was incorporated as an _integral_ part of {the syntax | the core | Phobos} of D.
> 
> That something happens in a game that has bearing on potentially a lot of objects or individuals in the game, is simply key in games development. Having to manually code all this is ridiculous at a time when there exist established and well understood mechanisms for it.
> 
> ---
> 
> Recently I had to write a command interpreter for a (in itself trivial) control language for a materials production process control program. The ease and joy of development was largely due to the std.regexp library. It was simply exhilarating.
> 
> If we could offer the game developers a smooth and transparent method for passing messages instead of a cumbersome design pattern, I think many shops would look upon us with a new eye.
> 
> In my humble opinion, the reason why QT is an absolute winner in the industry is simply because the signals/slot paradigm is central to that library. That in itself creates a sensation of robustness, quality, and a kind of completeness. The ease of utilizing it has most probably made the overall quality of the rest of the library much higher, by letting their programmers concentrate on the issues at hand instead of fighting with the trivialities of message passing.
> 
> We have to remember that interactive "real time" games development is the one area where signals (or messages) are an essential part of every major application. Both in the user interface and in the games engine logic itself.
> 
> ---
> 
> We only have to become the _preferred_ language in _one_ area! After that it'll automatically follow that we gain other areas and a huge general interest. ("If C is good enough for Unix itself, it has to be a good language. -- If D is good enouhg for some of the best games shops, it has to be a good language.")

D is unusually great for game development already. Multi-core processor games are the future. I remember Sweeny wrote some sort of wish list for a language he'd like to use to write games with and perhaps this should be looked at more closely.
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf#search=%22tim%20sweeny%20program%20language%22 


Plus games make a good 'extreme' case, it it works well with games, then it'll work well for everything since games combine system io, graphics, physics, networking, filesystems, and gui's all into one bundle.

Here's a game engine of the near future, which makes use of a multi-core system, just to show where the trend is heading...

http://www.youtube.com/watch?v=piMrNvdwYRU

From all of the above, my conclusion is
1) D needs to be able to harness multi-core processors and enable concurrency, this should be built-in
2) D needs good numerical computing (already there?), set support with union, intersect, etc through arrays?
3) Reliability, pretty much there, need 'Super Lint'
4) Easy access to powerful scripting languages (there)
5) Cross platform, it is there pretty much with GDC
6) Make an add on library or build into phobos (not sure if this is a good idea or not, probably better left as an add on library, unless these could somehow be buit-in to the language?)
  A) Path finding algorithms
  B) Scene graph algorithms
  C) Collision detection algorithms
  D) Physics simulation algorithms
  E) Sound propagation alg.
  F) FileSytem (like PhysFS www.icculus.org/physfs )

7) Support for pixel shading (not 100% sure how this could work)
8) Modularity (there). Make package system stronger somehow?
9) feature to extend functionality of the base class using

class CBase {}
class CNew extends CBase
{
}

Already there? Just took from Sweeny's PDF.

10) Array bounds check is there

I think this would be an exciting direction for D to move toward, and if we could suit Sweeny's needs (we could invite him to these newsgroups) and he uses D for his next engine (Unreal 4), all the C++ fans over at gamedev.net will faint :-P

~ Clay

Georg Wrede wrote:
> Seems to me that while D is marketed as a Systems development language, it will be quite some time before anybody has developed a System with D.
> 
> More plausible should be that one day games developers will find D /en masse/ because everything in D really is perfect for games development. 

<snip>

I'm not a prof. game developer, but I sure agree that D is perfect for it. Just the other day I was looking into the C++ source of civilization 4 (they released a good bulk of it) and thinking how nice it must be for the developers to turn this 125.000 LoC monster that takes more than 15 minutes to build into D. And then that is even a small part of the total code. (and oh my god, how ugly it is)

Just wondering whether it is a new language feature that game developers want. Tool, library and company support, general acceptance, marketing etc seems to be an important part of the equation.
From some developers at gamedev.net I understand that it is even the opposite: D is not a proven language and might have too much, not too few language features. Allow me to quote from a thread over there:

"Compared to C, C++ is a really really big language. It has a lot of features. It is so complex, in fact, that its features begin to interact in unintended ways. A great example of this is the thread on default arguments and virtual function binding. Who knew that those two features--which theoretically are unrelated--would combine to form unexpected-looking behavior? Or that template arguments could break preprocessor macros? There's plenty of examples of this, many chronicled on GotW and many more still being discovered by hapless C++ students and intrepid Boost developers.

And D goes so, so much further. The designers have a "why not" attitude towards adding useful-sounding features, with the result that D's feature list makes C++ look downright minimalist. 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.

I hope that D gains traction among some large body of hypothetical developers who, despite not being rabid D fans, end up using it in large applications with a long lifecycle. I hope this happens, because this is the only way to vet a language. Maybe I'm wrong; maybe D will all hang together and the features will turn out to mesh perfectly and I'll come to terms with the syntactic features I dislike and everything will be great. I just don't think that it's likely."

http://www.gamedev.net/community/forums/topic.asp?topic_id=409926&whichpage=2&#2759437

Lutger wrote:
> Just wondering whether it is a new language feature that game developers want. Tool, library and company support, general acceptance, marketing etc seems to be an important part of the equation.
>  From some developers at gamedev.net I understand that it is even the opposite: D is not a proven language and might have too much, not too few language features. Allow me to quote from a thread over there:
> 
> "Compared to C, C++ is a really really big language. It has a lot of features. It is so complex, in fact, that its features begin to interact in unintended ways. A great example of this is the thread on default arguments and virtual function binding. Who knew that those two features--which theoretically are unrelated--would combine to form unexpected-looking behavior? Or that template arguments could break preprocessor macros? There's plenty of examples of this, many chronicled on GotW and many more still being discovered by hapless C++ students and intrepid Boost developers.
> 
> And D goes so, so much further. The designers have a "why not" attitude towards adding useful-sounding features, with the result that D's feature list makes C++ look downright minimalist. 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.
> 
> I hope that D gains traction among some large body of hypothetical developers who, despite not being rabid D fans, end up using it in large applications with a long lifecycle. I hope this happens, because this is the only way to vet a language. Maybe I'm wrong; maybe D will all hang together and the features will turn out to mesh perfectly and I'll come to terms with the syntactic features I dislike and everything will be great. I just don't think that it's likely."

On the one hand, that is a valid concern. Many of the bug reports are coming from unexpected interactions between features. What can be done with the combination of all those capabilities has yet to be fully explored.

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!

clayasaurus skrev:
> Georg Wrede wrote:
<snip>
> 2) D needs good numerical computing (already there?), set support with union, intersect, etc through arrays?

Yes! Sets and limited range integers rules!

But unfortunately they seems to be like regular expressions in a way; if you understand them you totally love them and can not be without them, if not then you simply can not grasp what the fuzz is all about :(.

I have cooked up a template-solution for sets. But well, speed, good error messages, and an obvious syntax for th task would be nice things to have :(.


// Fredrik Olsson

clayasaurus wrote:
> Georg Wrede wrote:
> 
>> Seems to me that while D is marketed as a Systems development language, it will be quite some time before anybody has developed a System with D.

...

> http://www.youtube.com/watch?v=piMrNvdwYRU

Hey, these guys are from Finland!
And the demo was awesome.

(Would be nice to have a 4-way, 4gigs playbox. Santa, please!)

Otoh, I guess we should not aspire to convert established major players at this point. The reason being, if I were the chairman over there I'd be scared to switch to an unknown language, if for nothing else, at least all our C++ libraries would become pretty hard to use.

So IMHO the best potential converts would be 1-5 man shops who want to get some kind of edge on their competitors. Such a shop might develop a game that is "technologically" (mp, rendering, etc) unremarkable, but the game could be a winner because they can concentrate on what the _game_ is doing instead of battling with C++.

Suppose it's true that D gives (say) 30% more productivity than C++, then this shop should get it's products out way faster, and with less bugs.

>  From all of the above, my conclusion is
> 1) D needs to be able to harness multi-core processors and enable concurrency, this should be built-in

Not being an expert on this, does using several cores present some fundamental needs of change to a "regular" threading code?

> 5) Cross platform, it is there pretty much with GDC

I think it's still some time before we'd be comfortable on a non-x86 platform. But that ought to be plenty enough for us. More pressing would be to get a 64-bit DMD out, real soon.

> I think this would be an exciting direction for D to move toward, and if we could suit Sweeny's needs (we could invite him to these newsgroups) and he uses D for his next engine (Unreal 4), all the C++ fans over at gamedev.net will faint :-P

The one thing somebody heavyweight might use D for (for now) is for prototyping. Especially if they're smart enough to already demand that prototypes are not done in the final language.

There D could shine. Rapid coding, especially under pressure, is where I expect the productivity differences between D and C++ to really become conspicuous!

Heh, if I were a D salesman, I'd go to a programming shop, and ask for the _second_ fastest coder. I'd teach him D for two days, and then give both him and the fastest guy some moderately difficult assignment, to show to everybody what a difference the language really makes.

---

Back to the issue at hand, it's the smaller shops that would gain most from having SS implemented right in the language. Large operations probably would develop their own if it doesn't exist in the language, and once done, it would just become part of their culture. But the smaller shops really could benefit from it existing in the language itself. (Whether within syntax or the core library, as long as it is there, and trivially usable.)

---

I just remembered a funny thing. Back in the late 1980's when I first became aware of OO, I initially took it for granted that object instances would interact by something SS-like. Then when I got my Turbo Pascal 5.5 upgrade (1989, I think), I was disappointed when I found out all this fancy OO and "messaging" was just calling functions in structs. I thought this was a home-made hack below the quality and depth I expected from Borland.

Later, when I found out C++ did it the same way, it became "legitimate", and I thought that TP had actually implemented it quite subtly and smoothly.

But somehow the feeling stuck. I've always been disenchanted with OO that's just "calling functions in structs". And somehow I just can't help feeling that real OO simply needs threading and asynchronous message passing.

(Or maybe it's simply because instead of objects I was thinking of Subjects. A lot of the hoopla was like "this object sends a message" and the like. Maybe that's why I love Unix: the entire box is a Subject, and it contains other, live Subjects! "The other" boxes are just dead iron. They're objects to users, to viruses and to malware!)

A lot of code I see is using OO only to bag related functions together. Of course, there's nothing wrong with that -- it's a heck of a lot better than just having those functions laying freely around. But the dreams and promises of OO never did quite materialize as I expected.

Polymorphism is unrelated to this, and I'm happy with it as is. In the old days I used to wonder why Borland skipped multiple inheritance. I suspected it was because it was hard to do, but later I decided that they simply knew it wasn't worth it. With C++ multiple inheritance I always felt stupid, first I couldn't figure out compelling use cases, and then I couldn't help trying to grasp "a proper" understanding of the implications of inheritance networks. Well, turns out everybody else was stupid too, so now we've stuffed it right where the sun don't shine.

Lutger wrote:
> I'm not a prof. game developer, but I sure agree that D is perfect for it. Just the other day I was looking into the C++ source of civilization 4 (they released a good bulk of it) and thinking how nice it must be for the developers to turn this 125.000 LoC monster that takes more than 15 minutes to build into D. And then that is even a small part of the total code. (and oh my god, how ugly it is)

Some day some guys will port something like that to D, initially just for the heck of it. In addition to becoming famous and the First to have done it, they'll get a unique understanding of the issues. And it would look good in their CV, whether they apply for a C++ or D job.

> Just wondering whether it is a new language feature that game developers want. 

Probably not. I guess most would be more glad to have gotten rid of the majority of the unnecessary crap and dragstones that C++ has.

Mostly they'd be happy about the cleaner syntax and ease of actually writing code.

> Tool, library and company support, general acceptance, marketing etc seems to be an important part of the equation.

Tools, now that's a show stopper. Round trip UML, proper integration into Eclipse or MS IDEs, working debuggers, code analysis and metrics tols, etc... This should be enough to keep the bigger shops away.

>  From some developers at gamedev.net I understand that it is even the opposite: D is not a proven language and might have too much, not too few language features. Allow me to quote from a thread over there:
> 
> "Compared to C, C++ is a really really big language.
> ...
> And D goes so, so much further. The designers have a "why not" attitude towards adding useful-sounding features, with the result that D's feature list makes C++ look downright minimalist. 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?

Valid.

Except somehow I don't perceive D as a "bigger" language than C++. But I admit, this might just be a biased "feeling".

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

> I hope that D gains traction among some large body of hypothetical developers who, despite not being rabid D fans, end up using it in large applications with a long lifecycle. I hope this happens, because this is the only way to vet a language. Maybe I'm wrong; maybe D will all hang together and the features will turn out to mesh perfectly and I'll come to terms with the syntactic features I dislike and everything will be great. I just don't think that it's likely."
> 
> http://www.gamedev.net/community/forums/topic.asp?topic_id=409926&whichpage=2&#2759437 

Obviously he knows what he's talking about, and he's (at least superficially) familiar with D. And that's a heck of a lot better than being ignored by that community! :-)

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

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

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

Georg Wrede wrote:
> 
> 
> clayasaurus wrote:
>> Georg Wrede wrote:
> Otoh, I guess we should not aspire to convert established major players at this point. The reason being, if I were the chairman over there I'd be scared to switch to an unknown language, if for nothing else, at least all our C++ libraries would become pretty hard to use.
> 

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.


> <snip> Not being an expert on this, does using several cores present some fundamental needs of change to a "regular" threading code?
> 

I'm not an expert either, but I think it is pretty much having threading built-in to the language itself.

Georg Wrede wrote:
> [snip wonderful post]
> 
> In my humble opinion, the reason why QT is an absolute winner in the industry is simply because the signals/slot paradigm is central to that library. That in itself creates a sensation of robustness, quality, and a kind of completeness. The ease of utilizing it has most probably made the overall quality of the rest of the library much higher, by letting their programmers concentrate on the issues at hand instead of fighting with the trivialities of message passing.
> 
> We have to remember that interactive "real time" games development is the one area where signals (or messages) are an essential part of every major application. Both in the user interface and in the games engine logic itself.

I'm not a S&S guy myself, and I'm just beginning to grasp the concepts thanks to the posts here in the group.  I'm able to draw some parallels to web programming, and similar event models there, but I'm also finding that it's very much it's own animal.

One thing did occur to me the other night: would a full-fledged S&S in D implementation require AOP support?  I'm thinking of the "raise this signal when you're done executing" portion of S&S.

I think there's a way to add AOP into D *now*, if you don't mind using trampolines and other hackery to get the job done.  Provided that your app is reasonably thread safe, such a library might prove quite useful for all kinds of things - S&S and otherwise.

Thoughts?

> We only have to become the _preferred_ language in _one_ area! After that it'll automatically follow that we gain other areas and a huge general interest. ("If C is good enough for Unix itself, it has to be a good language. -- If D is good enouhg for some of the best games shops, it has to be a good language.")

Agreed.  While I had a false start myself moving toward webapps for D, I think we're much closer than we were.  But add to that the current turbulence and quiet revolution we've seen in web design techniques, and things seem farther away than ever.  FWIW I think that it may tip eventually, after I or someone gets a solution put together, but that's probably a long way off.

So forging ahead on this front (gaming) might prove to be a closer tipping-point for D.  If for no other reason, it'll be becuase it's just easier to distribute .exe files rather than convince web admins to install new stuff.  Client-side software FTW. ;)

-- 
- EricAnderton at yahoo