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:


<snip>

 2) D needs good numerical computing (already there?), set support with 
 union, intersect, etc through arrays?


Yes! Sets and limited range integers rules!

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

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


// Fredrik Olsson
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:


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


Sweeney has expressed interest in a new language so I don't think it 
would be too far fetched. No harm in trying, at least.



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


I'm not an expert either, but I think it is pretty much having threading 
built-in to the language itself.
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:


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


 
 Sweeney has expressed interest in a new language so I don't think it
 would be too far fetched. No harm in trying, at least.
 


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





 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.






<snip>

 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 

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 

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 

 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 



For Microsoft platforms I very much agree.  Though that leaves Sony, 

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!



 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 



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:


[snip]

 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:


 [snip]

 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.


 Some template judo we've seen is simply impressive, and if we get more 
 guys like that here who'd become interested in the other aspects, we 
 really might see something interesting.


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


 But on the other hand, I don't think this is a reason to be hesitant 
 to use D. If those more unusual combinations cause a problem, just 
 don't use them that way. It isn't necessary to remove the features 
 from the language!


 
 The C++ guys certainly shouldn't complain, they already do it every day.
 
 And not using the entire feature set in each source file might be a good 
 idea with any language. :-)


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



 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&



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&

 


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


 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.


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