www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Games people play

reply Georg Wrede <georg.wrede nospam.org> writes:
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.")
Sep 27 2006
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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%20p ogram%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
Sep 27 2006
next sibling parent Fredrik Olsson <peylow gmail.com> writes:
clayasaurus skrev:
 Georg Wrede wrote:

 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
Sep 28 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Sep 28 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Georg Wrede wrote:
 
 
 clayasaurus wrote:
 Georg Wrede wrote:

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.
Sep 28 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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.

Hmm. Maybe you're right!
Sep 28 2006
prev sibling next sibling parent David Medlock <noone nowhere.com> writes:
clayasaurus wrote:
 Georg Wrede wrote:
 


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

I think the best use of those are 'vectorized' or data-parallel operations. D is suited for this but not in its current incarnation. -DavidM
Sep 28 2006
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
clayasaurus wrote:

 Georg Wrede wrote:
 
 
 clayasaurus wrote:
 Georg Wrede wrote:

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.

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. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Sep 28 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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>.

Sep 28 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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

Sep 28 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
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.
Sep 28 2006
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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�
Sep 27 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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!
Sep 27 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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. :-)
Sep 28 2006
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.



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

But the C++ guys do complain. For every thread on C++ at gamedev, there is no end to the complaints of experienced developers (I'm not counting fanboys). Unexpected interactions between features and undefined behavior is one source of frustration, what makes C++ complex. If game developers are to move to a different language than C++, this has to be better, not the same. In this light, C# may look more favorably to some (indie at least, who don't need to port to all platforms). More lightweight, more tools, libraries, company support. I think if you want to attract game developers, you will have to compete with C# not C++. I'm willing to bet most sane C++ developers are already convinced they want to switch language if migration costs permit it. I don't know if not using features is a valid option, because it's based on the premise that it's understood already how exactly they will interact with other features, and that 3rd party libraries will not use them. Even if this is so, it does increase complexity of development. Is this viable in a project with, say, half a million lines of code?
Sep 28 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Lutger wrote:
 
 If game developers are to move to a different language than C++, this 
 has to be better, not the same. In this light, C# may look more 
 favorably to some (indie at least, who don't need to port to all 
 platforms). More lightweight, more tools, libraries, company support. I 
 think if you want to attract game developers, you will have to compete 
 with C# not C++.

For Microsoft platforms I very much agree. Though that leaves Sony, Nintendo, and Apple as potential target vendors where C# is unlikely to be supported. Cellphones and such as a possibility as well, though there D would be competing with Java.
 I'm willing to bet most sane C++ developers are already 
 convinced they want to switch language if migration costs permit it.

Another big issue is support tools. Without solid debug tool support, D will be a hard sell to most companies.
 I don't know if not using features is a valid option, because it's based 
 on the premise that it's understood already how exactly they will 
 interact with other features, and that 3rd party libraries will not use 
 them. Even if this is so, it does increase complexity of development.
 
 Is this viable in a project with, say, half a million lines of code?

It's not like this is a new problem. Until just a few years ago, most popular C++ compilers were pretty finicky. In fact I could time on a stopwatch how long it would take me to crash VC6, and VC6 is still used for a lot of projects. Sean
Sep 28 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Lutger wrote:
 Georg Wrede wrote:
 
 Walter Bright wrote:
 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. :-)

But the C++ guys do complain. For every thread on C++ at gamedev, there is no end to the complaints of experienced developers (I'm not counting fanboys). Unexpected interactions between features and undefined behavior is one source of frustration, what makes C++ complex.

Ah, my point exactly: they shouldn't complain about a few isolated "feature clash problems" in D. "Don't complain about eating bean stew when what you've eaten for years is just pig fodder." Except D is more like ice cream, IMHO. ;-)
 If game developers are to move to a different language than C++, this 
 has to be better, not the same. 

I'd like to see the person who says D is not *much* better in this respect!
 In this light, C# may look more 
 favorably to some (indie at least, who don't need to port to all 
 platforms). 

You can't be serious! Maybe for an indie writing a new tic-tac-toe, but for Serious Development, I sure hope not.
 More lightweight, more tools, libraries, company support. I 
 think if you want to attract game developers, you will have to compete 
 with C# not C++. 

That's another thing. Tools and libraries we lack, no denying.
 I don't know if not using features is a valid option, because it's based 
 on the premise that it's understood already how exactly they will 
 interact with other features, and that 3rd party libraries will not use 
 them. Even if this is so, it does increase complexity of development.

The C++ guys should be used to it.
 Is this viable in a project with, say, half a million lines of code?

I'd say not. But to start the next project in a new language (after suitably trying it out with a couple of prototyping projects), then yes.
Sep 28 2006
next sibling parent reply J Duncan <jtd514 nospam.ameritech.net> writes:
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. 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.

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.

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!"
Sep 28 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Sep 28 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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
Sep 28 2006
parent Walter Bright <newshound digitalmars.com> writes:
Kyle Furlong wrote:
 Walter Bright wrote:
 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.

It's sort of like my relationship with tools. My inclination is to go to Tool Town and buy every tool they have. I want them all; 1" drive socket sets, welders, air tools, etc. The only solution I've found is to only buy a tool if I have an immediate need for it in a project I'm working on.
Sep 28 2006
prev sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
On Thu, 28 Sep 2006 13:34:15 -0700, Walter Bright  
<newshound digitalmars.com> wrote:


 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.

I have to agree with this. S&S seems like a great pattern, but I'm worried about the urge to implement the current fads into the language just because they're "so great". Someday, the excitement may fade when an improvement on the pattern surfaces, and we could be left with a feature in there that takes on a form altogether vestigual. Of course, this is a risk of many language components, but I think D has to slow down on feature additions for awhile to let alternate solutions aggregate (a stress test of the language of sorts). Nonetheless, it would certainly be fun to explore syntax alternatives for S&S, just to see what it would be like. I suppose if the pattern were generic enough, it could be interesting. Another note, I've been reading up on S&S, and while its a fascinating pattern (although I dislike the signal/slot naming convention -- it seems to describe the solution unintuitively), I wonder how well it mixes with concurrency patterns. I mean, we should really be looking at the broader application of it. It really should have a combined application with concurrency. That said, I noticed that CSP, which deals with "message-passing" and interprocess communication through "channels" has similarities to S&S, except in the context of concurrency. Newer experiments in CSP have been exploring the passing of processes/threads/functions in addition to data... while here we are talking about concurrency, S&S appears to be messaging of a similar sort, except that it doesn't describe the threading domain. Since concurrency is becoming such a hot issue, I really think we have to look at the broader scope of S&S in this context (I believe Qt S&S is said to be thread-safe while the boost alternative is not). Is anybody here able to share how threading works with S&S? Is it complicated? Is in cleanly integrated? I really think these two ideas should merge together cleanly... perhaps it can be done with a CSP implementation. -JJR
Oct 03 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
John Reimer wrote:
 On Thu, 28 Sep 2006 13:34:15 -0700, Walter Bright 
 <newshound digitalmars.com> wrote:

 S&S seems like a great pattern, but I'm 
 worried about the urge to implement the current fads into the language 
 just because they're "so great".  Someday, the excitement may fade when 
 an improvement on the pattern surfaces, and we could be left with a 
 feature in there that takes on a form altogether vestigual.  

Yes. For statically checked S&S, templates & mixins seem like they provide basically all that is needed to implement a good solution, (maybe there's still some weak reference business that needs to be sorted out, but it looks like it's mostly there). The main wart is that you have to have a different template for each number of arguments, resulting in repetitive code. Some form of Variadic Templates would be very nice to have there. So instead of template Signal(T1) // for one argument ... template Signal(T1, T2) // for two arguments ... template Signal(T1, T2, T3) // for three arguments ... template Signal(T1, T2, T3, T4) // for four arguments ... template Signal(T1, T2, T3, T4, T5) // for five arguments ... template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ... template Signal(etc... You can just have one template template Signal(...) // for any number of arguments ... But something more is needed for Dynamic Qt-like S&S. Some sort of compile-time introspection seems a minimal requirement. I think some way to tag particular method like Qt's "slot:" keyword will also be necessary to make it usable. Anyway you need some way to say "do something with this method" and do it at the point of declaration rather than in the constructor or elsewhere. If there were a generic decorator mechanism, that would take care of it I think. 'slot' could be a particular user-defined decorator that takes a method and adds that method to a static call-by-name table for the class, all at compile time. Decorators also make things like Aspect oriented programming, and precondition/postcondition easier. Can also use them to implement things like "synchronized". Other uses can be found here: http://www.python.org/dev/peps/pep-0318/ Anyway decorators are a very useful concept I think. It's kind of like a mixin declared outside a scope rather than inside. Like a 'mixout'. Mixin's inject some code inside something. A decorator wraps some code around the outside of something. --bb
Oct 03 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:
 Yes.  For statically checked S&S, templates & mixins seem like they 
 provide basically all that is needed to implement a good solution, 
 (maybe there's still some weak reference business that needs to be 
 sorted out, but it looks like it's mostly there).  The main wart is that 
 you have to have a different template for each number of arguments, 
 resulting in repetitive code.  Some form of Variadic Templates would be 
 very nice to have there.
 
 So instead of
 template Signal(T1) // for one argument ...
 template Signal(T1, T2) // for two arguments ...
 template Signal(T1, T2, T3) // for three arguments ...
 template Signal(T1, T2, T3, T4) // for four arguments ...
 template Signal(T1, T2, T3, T4, T5) // for five arguments ...
 template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
 template Signal(etc...
 
 You can just have one template
 template Signal(...) // for any number of arguments ...

That would be better, but the user doesn't see that code, just the library implementer. So it isn't so bad.
 But something more is needed for Dynamic Qt-like S&S.  Some sort of 
 compile-time introspection seems a minimal requirement.  I think some 
 way to tag particular method like Qt's "slot:" keyword will also be 
 necessary to make it usable.  Anyway you need some way to say "do 
 something with this method" and do it at the point of declaration rather 
 than in the constructor or elsewhere.

I don't understand. Exactly what needs to be done at compile time that can't be done with the mixin method?
Oct 03 2006
next sibling parent reply J Duncan <me nospam.com> writes:
Walter Bright wrote:
 Bill Baxter wrote: 
 
 But something more is needed for Dynamic Qt-like S&S.  Some sort of 
 compile-time introspection seems a minimal requirement.  I think some 
 way to tag particular method like Qt's "slot:" keyword will also be 
 necessary to make it usable.  Anyway you need some way to say "do 
 something with this method" and do it at the point of declaration 
 rather than in the constructor or elsewhere.

I don't understand. Exactly what needs to be done at compile time that can't be done with the mixin method?

reflection data to allow dynamic method connection at runtime by identifier.....
Oct 03 2006
parent Walter Bright <newshound digitalmars.com> writes:
J Duncan wrote:
 
 
 Walter Bright wrote:
 Bill Baxter wrote:
 But something more is needed for Dynamic Qt-like S&S.  Some sort of 
 compile-time introspection seems a minimal requirement.  I think some 
 way to tag particular method like Qt's "slot:" keyword will also be 
 necessary to make it usable.  Anyway you need some way to say "do 
 something with this method" and do it at the point of declaration 
 rather than in the constructor or elsewhere.

I don't understand. Exactly what needs to be done at compile time that can't be done with the mixin method?

reflection data to allow dynamic method connection at runtime by identifier.....

That's not compile time <g>. The only way I can see a need for this at runtime is if the classes are coming from a DLL that the compiler doesn't know about. The compiler does know about everything that is statically linked to it.
Oct 03 2006
prev sibling next sibling parent Josh Stern <josh_usenet phadd.net> writes:
On Tue, 03 Oct 2006 22:04:03 -0700, Walter Bright wrote:

 Bill Baxter wrote:
 Yes.  For statically checked S&S, templates & mixins seem like they 
 provide basically all that is needed to implement a good solution, 
 (maybe there's still some weak reference business that needs to be 
 sorted out, but it looks like it's mostly there).  The main wart is that 
 you have to have a different template for each number of arguments, 
 resulting in repetitive code.  Some form of Variadic Templates would be 
 very nice to have there.
 
 So instead of
 template Signal(T1) // for one argument ...
 template Signal(T1, T2) // for two arguments ...
 template Signal(T1, T2, T3) // for three arguments ...
 template Signal(T1, T2, T3, T4) // for four arguments ...
 template Signal(T1, T2, T3, T4, T5) // for five arguments ...
 template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
 template Signal(etc...
 
 You can just have one template
 template Signal(...) // for any number of arguments ...

That would be better, but the user doesn't see that code, just the library implementer. So it isn't so bad.

Agreed, not a significant issue issue in this case, though the variadic feature might have saved the library writer (or future application authors) some time and cut down on some parsing overhead.
 But something more is needed for Dynamic Qt-like S&S.  Some sort of 
 compile-time introspection seems a minimal requirement.  I think some 
 way to tag particular method like Qt's "slot:" keyword will also be 
 necessary to make it usable.  Anyway you need some way to say "do 
 something with this method" and do it at the point of declaration rather 
 than in the constructor or elsewhere.

I don't understand. Exactly what needs to be done at compile time that can't be done with the mixin method?

It would be nicer to implement S&S without the need for modifying source code of existing classes or adding overhead to all uses of those classes.
Oct 03 2006
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 So instead of
 template Signal(T1) // for one argument ...
 template Signal(T1, T2) // for two arguments ...
 template Signal(T1, T2, T3) // for three arguments ...
 template Signal(T1, T2, T3, T4) // for four arguments ...
 template Signal(T1, T2, T3, T4, T5) // for five arguments ...
 template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
 template Signal(etc...

 You can just have one template
 template Signal(...) // for any number of arguments ...

That would be better, but the user doesn't see that code, just the library implementer. So it isn't so bad.

Well I may be crazy, but I tend to prefer using libraries with readable code. It makes things so much easier to debug when something goes wrong. I cringe every time I have some crash inside of STL or some Boost library in C++. The code is just terrible for readability. Yes, ideally I shouldn't have to care how it's implemented, but in practice every once in a while it is useful to be able to actually read the code. But you are right, it is not a show-stopper. Just makes it less convenient, and makes it look like it was implemented more "despite" the language than "thanks to" it.
 But something more is needed for Dynamic Qt-like S&S.  Some sort of 
 compile-time introspection seems a minimal requirement.  I think some 
 way to tag particular method like Qt's "slot:" keyword will also be 
 necessary to make it usable.  Anyway you need some way to say "do 
 something with this method" and do it at the point of declaration 
 rather than in the constructor or elsewhere.

I don't understand. Exactly what needs to be done at compile time that can't be done with the mixin method?

The mixins are fine for Signals, but I'm talking about a dynamically callable method, or Qt-like "slot". I was assuming a world in which methods are not dynamically callable by default, as is the case with current C++/Qt. In that case, the Qt way is for users to flag methods that should have extra runtime call-by-name code generated for them by putting the 'slots:' keyword before the method(s). Then the "moc" compiler generates this code. I believe it's already possible with templates to make a method callable by name if you provide a name to use, and call some sort of register!(method, "method") template. PyD does a related kind of thing, and I wrote my own dynamic sigslot implementation in C++ that does that (quite hacky, but it works), so it must be possible in D too. But having to call "register!(...)" somewhere is not as convenient (or as easy to maintain) as just being able to flag the method right at the place of declaration. Of course the outside-the-class "register!()" technique is useful too, for those cases where you can't modify the class's code for whatever reason. --bb For kicks, here's a snippet of my dynamic sigslot implementation in C++. I gave up after 4 arguments because it became too tedious and too much of an eyesore. I was originally planning to do 9. template <class ClassT> class _SlotCaller0 : public _SlotCaller<ClassT> { protected: typedef void (ClassT::*MethT)(); MethT mMeth; friend DynSigSlot; _SlotCaller0(ClassT* obj, MethT m) : _SlotCaller<ClassT>(obj), mMeth(m) {} virtual void call(va_list args) { (mObj->*mMeth)(); } }; template <class ClassT, class Arg1T> class _SlotCaller1 : public _SlotCaller<ClassT> { protected: typedef void (ClassT::*MethT)(Arg1T); MethT mMeth; friend DynSigSlot; _SlotCaller1(ClassT* obj, MethT m) : _SlotCaller<ClassT>(obj), mMeth(m) {} virtual void call(va_list args) { Arg1T a1 = DSS_VARG(args,Arg1T); (mObj->*mMeth)( a1 ); } }; template <class ClassT, class Arg1T, class Arg2T> class _SlotCaller2 : public _SlotCaller<ClassT> { protected: typedef void (ClassT::*MethT)(Arg1T,Arg2T); MethT mMeth; friend DynSigSlot; _SlotCaller2(ClassT* obj, MethT m) : _SlotCaller<ClassT>(obj), mMeth(m) {} virtual void call(va_list args) { Arg1T a1 = DSS_VARG(args, Arg1T); Arg2T a2 = DSS_VARG(args, Arg2T); (mObj->*mMeth)( a1, a2 ); } }; template <class ClassT, class Arg1T, class Arg2T, class Arg3T> class _SlotCaller3 : public _SlotCaller<ClassT> { protected: typedef void (ClassT::*MethT)(Arg1T,Arg2T,Arg3T); MethT mMeth; friend DynSigSlot; _SlotCaller3(ClassT* obj, MethT m) : _SlotCaller<ClassT>(obj), mMeth(m) {} virtual void call(va_list args) { Arg1T a1 = DSS_VARG(args, Arg1T); Arg2T a2 = DSS_VARG(args, Arg2T); Arg3T a3 = DSS_VARG(args, Arg3T); (mObj->*mMeth)( a1, a2, a3 ); } }; template <class ClassT, class Arg1T, class Arg2T, class Arg3T, class Arg4T> class _SlotCaller4 : public _SlotCaller<ClassT> { protected: typedef void (ClassT::*MethT)(Arg1T,Arg2T,Arg3T,Arg4T); MethT mMeth; friend DynSigSlot; _SlotCaller4(ClassT* obj, MethT m) : _SlotCaller<ClassT>(obj), mMeth(m) {} virtual void call(va_list args) { Arg1T a1 = DSS_VARG(args, Arg1T); Arg2T a2 = DSS_VARG(args, Arg2T); Arg3T a3 = DSS_VARG(args, Arg3T); Arg4T a4 = DSS_VARG(args, Arg4T); (mObj->*mMeth)( a1, a2, a3, a4 ); } };
Oct 04 2006
prev sibling next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 Yes.  For statically checked S&S, templates & mixins seem like they 
 provide basically all that is needed to implement a good solution, 
 (maybe there's still some weak reference business that needs to be 
 sorted out, but it looks like it's mostly there).  The main wart is 
 that you have to have a different template for each number of 
 arguments, resulting in repetitive code.  Some form of Variadic 
 Templates would be very nice to have there.

 So instead of
 template Signal(T1) // for one argument ...
 template Signal(T1, T2) // for two arguments ...
 template Signal(T1, T2, T3) // for three arguments ...
 template Signal(T1, T2, T3, T4) // for four arguments ...
 template Signal(T1, T2, T3, T4, T5) // for five arguments ...
 template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
 template Signal(etc...

 You can just have one template
 template Signal(...) // for any number of arguments ...

That would be better, but the user doesn't see that code, just the library implementer. So it isn't so bad.

Perhaps, but then what happens when I need to use more arguments than such a template library provides for? Suddenly, the problem is thrown in the library user's lap. -- - EricAnderton at yahoo
Oct 04 2006
prev sibling parent reply Kristian <kjkilpi gmail.com> writes:
On Wed, 04 Oct 2006 08:04:03 +0300, Walter Bright  
<newshound digitalmars.com> wrote:
 Bill Baxter wrote:

 arguments, resulting in repetitive code.  Some form of Variadic  
 Templates would be very nice to have there.
  So instead of
 template Signal(T1) // for one argument ...
 template Signal(T1, T2) // for two arguments ...
 template Signal(T1, T2, T3) // for three arguments ...
 template Signal(T1, T2, T3, T4) // for four arguments ...
 template Signal(T1, T2, T3, T4, T5) // for five arguments ...
 template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
 template Signal(etc...
  You can just have one template
 template Signal(...) // for any number of arguments ...

That would be better, but the user doesn't see that code, just the library implementer. So it isn't so bad.

Hey, library writers are people too! ;) Actually I think it's absurd to divide people into two groups: ones writing libraries and ones using them. If you write something more complex than tiny programs, you're gonna need all the same features and tricks than library writers. Eventually. I think library writers and other heavy duty users would be good test subjects, wouldn't they? What they will need, the language should provide. ;)
Oct 04 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Kristian wrote:
 On Wed, 04 Oct 2006 08:04:03 +0300, Walter Bright 
 <newshound digitalmars.com> wrote:
 Bill Baxter wrote:

 arguments, resulting in repetitive code.  Some form of Variadic 
 Templates would be very nice to have there.
  So instead of
 template Signal(T1) // for one argument ...
 template Signal(T1, T2) // for two arguments ...
 template Signal(T1, T2, T3) // for three arguments ...
 template Signal(T1, T2, T3, T4) // for four arguments ...
 template Signal(T1, T2, T3, T4, T5) // for five arguments ...
 template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
 template Signal(etc...
  You can just have one template
 template Signal(...) // for any number of arguments ...

That would be better, but the user doesn't see that code, just the library implementer. So it isn't so bad.

Hey, library writers are people too! ;) Actually I think it's absurd to divide people into two groups: ones writing libraries and ones using them. If you write something more complex than tiny programs, you're gonna need all the same features and tricks than library writers. Eventually.

Amen to that! But I think Walter's point is more that it's encapsulated. After you write that gobbledygook once, it becomes an implementation detail you can forget about. At least for that one library. Contrast that with something like the hacks for adding OO support to C. Yes you can get inheritance and polymorphism, but you're still stuck with ugly syntax in your face every time you try to *use* it like: toolkitWidgetResize(widget, W,H); instead of widget->Resize(W,H); In the lack-of-variadic-template-args case Walter is arguing that you don't see it. But I take issue with that, because I will indeed see it the first time I pass it a bogus parameter and the compiler chokes on it. It's going to point me right at that file with the gobbledygook and tell me there's something wrong there. But here's what Walter's Signal class could look like with variadic template parameters. I've assumed the types of the variadic arguments can be accessed by some sort of static type array "_targuments": template Signal(...) // for any number of arguments { // _targuments.args can serve in place of a list of typed arguments // so this would expand to T1 a, T2 b for Signal(T1,T2) void emit( _targuments.args ) { foreach (dg; slots) // _targuments.args can be treated like varargs // they show up in the _arguments list dg(_arguments); //(can you forward arguments like this D?) } // _targuments.types expands to T1,T2 for Signal(T1,T2) void connect( void delegate(_targuments.types) dg) { slots ~= dg; } void disconnect( void delegate(_targuments.types) dg) { for (size_t i = 0; i < slots.length; i++) { if (slots[i] == dg) { if (i + 1 == slots.length) slots = slots[0 .. i]; else slots = slots[0 .. i] ~ slots[i + 1 .. length]; } } } private: void delegate(_targuments.types)[] slots; } I would prefer something user named like here: http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html rather than the "magic" variable, but that's a critique that applies to regular function varargs too. Might as well put that in a separate message. --bb
Oct 04 2006
prev sibling parent reply Jeff <psychobrat gmail.com> writes:
 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!"

If I'm not mistaken, given the features already in D, specific S&S functionality would be a job for the standard library, wouldn't it?
Sep 28 2006
parent J Duncan <me nospam.com> writes:
Jeff wrote:
 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!"

If I'm not mistaken, given the features already in D, specific S&S functionality would be a job for the standard library, wouldn't it?

I agree, it should at least be in phobos.....
Sep 28 2006
prev sibling parent Josh Stern <josh_usenet phadd.net> writes:
 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.
Sep 28 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
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.

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.
Sep 28 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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&
hichpage=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! :-)
Sep 28 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Sep 28 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Sep 28 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Sigh, this really ought to be nailed to the nearest church door (like 
Martin Luther did). Or to the cover of CUJ.

Walter Bright wrote:
 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.

Sep 28 2006
prev sibling parent Nicolas Janin <nicolas.janin remove_this_part.ifrance.com> writes:
Lutger a écrit :
 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& hichpage=2&#2759437

Hello, The risk of clash/inconsistencies between language features and the difficulties added in optimizing the compiler are two good reasons why the core language must stay as clean as possible. So features such as Signals & slots should IMHO be kept in libraries (maybe in Phobos) and not included in the language, simply because the language was not designed with this kind of feature in mind from the start. I'd say the same thing for the support of multi-processing. D can only offer very good multi-threading and message-passing capabilities via dedicated libraries. Just for the record, the best game examples written in D I know of are the shooter games by Kenta Cho: http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html (source code included in the downloads). I think they demonstrate very well the gaming performances of D (it looks like they were written in C).
Oct 07 2006
prev sibling next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
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
Sep 28 2006
parent reply Brad Anderson <brad dsource.org> writes:
Pragma wrote:

[snip]

 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.

[snip] Are you talking about Ajax here? Frameworks like Rails / Django? Just trying to clarify your point here. Assuming that Ajax is what you're referring to, the need for a kick-ass server side remains, and it's where DSP could shine. Kris has said that small mods to Mango could allow it to handle the different demands of Ajax calls more effectively, as Jetty's new version does. Couple that with a really easy server-side framework that wraps up a bunch of WS complexity and you're on your way. Oooh, I'm getting OT again... shocking. I'd like to put this delicately, but I'm not sure how. In my mind, there's a strength of development that exists in game devs that's not there in web devs (maybe I'm just talking about myself ;) ). However, I would guess the web devs are out there in larger numbers. Perhaps this crowd would benefit from D's improvements and be the market Georg talks about. BA
Sep 28 2006
next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Brad Anderson wrote:
 Pragma wrote:
 
 [snip]
 
 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.")

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.

[snip] Are you talking about Ajax here? Frameworks like Rails / Django? Just trying to clarify your point here. Assuming that Ajax is what you're referring to, the need for a kick-ass server side remains, and it's where DSP could shine. Kris has said that small mods to Mango could allow it to handle the different demands of Ajax calls more effectively, as Jetty's new version does. Couple that with a really easy server-side framework that wraps up a bunch of WS complexity and you're on your way. Oooh, I'm getting OT again... shocking.

As a matter of fact, yes I am. ;) I've spent the better part of the past few months working on AJAX-based software (on the job at that!). Rants about browser readyness* for deep Javascript apps aside, I've noticed that a grammar like DSP (as originally concieved) is becomming increasingly irrelevant for web-applications; look at Ruby on Rails. Something that talks AJAX and WebSerivces as it's native tounge is really the way forward, and I am 0% complete on a D based solution there. Granted, Mango+DDL is still how this will happen, but that's all just the underpinnings. (* okay, one rant: IE's JS debugging support is deplorable enough to satisfy several anti-patterns *and* violate parts the Geneva Convention at the same time.)
 
 I'd like to put this delicately, but I'm not sure how.  In my mind, there's a
 strength of development that exists in game devs that's not there in web devs
 (maybe I'm just talking about myself ;) ).  However, I would guess the web
 devs are out there in larger numbers.  Perhaps this crowd would benefit from
 D's improvements and be the market Georg talks about.

Well put, and you're not just talking about yourself. Yea, some of us walk that line, but for the most part everyone has a focus and that tends to fall mostly within one problem domain or another. There's no shame in that. We can't all be John Carmack, Bjarne Stoustrup, or even Walter. The rest of us have to settle for using their software instead. -- - EricAnderton at yahoo
Sep 28 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Brad Anderson wrote:
 
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.


I'd like to put this delicately, but I'm not sure how. In my mind, there's a strength of development that exists in game devs that's not there in web devs (maybe I'm just talking about myself ;) ). However, I would guess the web devs are out there in larger numbers. Perhaps this crowd would benefit from D's improvements and be the market Georg talks about.

Hmm. I think I see. :-) At any rate, there are more web developers than games developers, so I don't have a problem with it. My original point, after all, was that we do need to find a proper target and focus some effort in actually capturing it. If it's games developers, web devs, whatever -- the point is that we serve D's interest best by giving that group our best. (Simply because we can't give our best to everybody, yet.) 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.) Any web developers here? What would _you_ like, wish, need, if you were just starting a web project in D?? -- Hmm. Actually, this is _the_ wrong forum to ask that. Anybody know somebody who's contemplating and who's not yet a D convertee? What's he thinking? What does he need? Or wish to get him up to speed?
Sep 28 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
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.
Sep 28 2006
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Georg Wrede wrote:
 Any web developers here? What would _you_ like, wish, need, if you were
 just starting a web project in D??

The most valuable thing would be a agile, customizable, modern framework for doing serious, large scale web apps. Maybe a low level framework. I've done some coding with Ruby on Rails lately on smallish projects (<40 db tables, <80 html "pages"). IMO the biggest weaknesses in Ruby are it's speed and lack of compile-time syntax/type checking. I haven't studied these IL-compilers (e.g http://rubyforge.org/projects/cardinal/) a lot - maybe they'll fix the latter issue. However, there's not much point in fighting Ruby on its very own battleground. Even with reflection, high level structures, superb web application libraries a general purpose c-like language cannot provide all the dynamical functionality that Ruby and Rails have. It would also be quite stupid to only stick with Ruby. Complex systems seem to be hybrids consisting of several languages&environments for different purposes. Currently these lower level systems are made with existing languages that may not be optimal for their purpose. C does not provide much support for complex architectures. C++ has its problems. I think the solution would be to focus on architectural issues in D. Templates and reflection fit nicely here. So do also lazy evaluation, design by contract and D scopes. One thing I don't understand in D is AFAICT that the abstraction of classes is somewhat broken, namely the use of interfaces. Last time I checked it was quite impossible to implement all GoF design patterns without quirks because you have to cast interfaces to (some unknown) classes before being able to call their public methods. How can a predefined framework know beforehand about classes made by the end user.
Sep 28 2006
prev sibling parent reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Georg Wrede wrote:

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

Two years ago I was struggling with getting reflection and introspection done with C++ for the 3D engine I'm developing and was looking for how other systems are doing it; I also came across the D homepage, but not considered it an alternative yet. However 3 unsuccessfull months later I completely dropped the idea of getting my module system working with C++. Obj-C seemed like a good alternative, though I don't like the mix of Smalltalk with the constraints of plain C. Then I remembered an language called D. Some google and a compiler install later I fell in love with it, though it took me a while to fully understand it's full power. For example I got a whole bunch of OCaml code, that I used to generate C code with for certain mathematical operations (I got that idea from the FFTW project). But now it seems that D's metaprogramming features, together with the optimization algorithms of modern compilers can do the same whilst keeping it all in the same language. So I decided to do a hard cut, venturing a huge project conversion, which of course requires me to learn a lot of D, and I'm far finished from grasping all possibilities. However using D for a game engine also brings a bit development overhead with it. For example my engine has a global virtual file system, memory management, garbage collection etc. i.e. systems that could run in parallel to a language runtime, but it's cleaner to have a unique runtime covering all parts. So I provide my own version of Phobos, stripped down to the minimal required subset of features. The rest is covered by engine specific modules. One might ask, why a propritary runtime environment is neccesary at all; this is a quite complicated topic, among the reasons is, that one might want to deliver binary modules within packages, that are to be unpacked at runtime tepending on the executing environment, aka universal binary. Another reason is, that only a very small codebase is actually plattform dependent, and it makes no sense to recompile the whole stuff for different plattforms. Funny enough the OpenGL API, which by itself is plattform independent, requires different binaries for Windows and the whole rest, which is due to different calling conventions. I was thinking of developing a runtime trampoline code generator, that would load and link the OpenGL stuff upon startup. But since there are also some plattform dependent thing to do prior to initializing OpenGL I would have to plattform dependent compile the OpenGL module anyway. Apropos plattform dependency. Also here D is great: Just segregate the code with version statements and you're done, no ifdefs and similair hard-to-debug-if-you've-forgot-an-endif stuff. But there's still a lot of work to be done. Wolfgang Draxinger =C2=B9some graphic cards can do float/multisample within one buffers others have it mutually exclusive. --=20 E-Mail address works, Jabber: hexarith jabber.org, ICQ: 134682867 GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E
Oct 01 2006
parent Walter Bright <newshound digitalmars.com> writes:
Wolfgang Draxinger wrote:
 So I decided to do a hard cut, venturing a huge project
 conversion, which of course requires me to learn a lot of D, and
 I'm far finished from grasping all possibilities.

None of us has come close to grasping all the possibilities of what can be done with D. Your project experience sounds very interesting. Do you think you could write a brief article about it? I think as a case history it could be very good.
Oct 02 2006