www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D and the world

reply janderson <askme me.com> writes:
Its about time for another round of how D can conquer the world.

The way I see it D has 2 options, provide an easy way for C++ users to 
switch over or become D.net.  The problem is, it is extremely 
impracticable to switch over to D because:

1) Everything is already in C++.  It would take months to switch over. 
Time that no one has.
2) Many API's are in C++.  Porting is too dam time consuming.  There are 
so many API's that companies use, it is impossible to have them all ported.
3) Learning.  People are resistant to learning new things.  I think this 
hurdle is easiest to jump if the other 2 are in place.

The C++ option:

There are several ways this could be done however all would be most 
effective.

1) Provide an easy way to link directly with C++ (preferably MSVC), such 
that we can write in C++ an D simultaneously and without having to write 
wrapper code.

2) Provide a way to import C++ APIs that takes practically no time to 
implement.

3) Provide a wizard that will convert a C++ project to D.  It needs to 
be so easy, you don't have to even think about it.

This seems like its asking for a lot.  However a month or 2 was spent 
setting up D so it could be integrated with C++ within a couple of 
clicks, it would pay huge dividends.  This would mean that it would be 
much easier for anyone at a C++ factory to convince managers of D's cost 
befits.

I think many C++ programmers are looking for a better alternative 
however they can't switch to D because of the afore mentioned problems. 
  If this was done right, you could practically convert many of the C++ 
community. Not unlike C++ did to C. I doubt you'll get many C converts 
though because most of the ones remaining can't leave C for other reasons.


D.Net option:


D provides.  With products like XNA and a decent development 

that works with net (that was in development ages ago), would give D a 
foothold for the next generation of programmers.  I do however think 
that D will be a harder sell on this platform.

Final comments

It may be possible for D to find its way into main stream by a nitch 
market however I think the chances here are low.  Of course one possibly 
here is the mobile phone industry.  Even so, D runs the risk of being a 
one-time-wonder that is dependent on the phone companies continued support.

Note that I discount Java because there is less overlap in 
functionalities.  Furthermore note that my point of view is from the 
game industry and the situation may be completely different for business.

So if D wants to become big (say in the next year), I think some time 
invested in supporting C++ is its best bet.

-Joel
Apr 22 2007
next sibling parent reply Xinok <xnknet gmail.com> writes:
D only needs two things, though two very big things:

1) A proper IDE
2) Many more libraries

The language itself, D, offers enough to make it a practical choice over 
C++.

more, and because of Microsoft's resources, it has a proper IDE and tons 


Apr 22 2007
next sibling parent janderson <askme me.com> writes:
Xinok wrote:
 D only needs two things, though two very big things:
 
 1) A proper IDE
 2) Many more libraries
 
 The language itself, D, offers enough to make it a practical choice over 
 C++.

 more, and because of Microsoft's resources, it has a proper IDE and tons 


or Java. It appears to me, that many of the 3rd party libraries I use on a day to day basis would never become part of these many-libraries. People simply don't want to re-invent the wheel. -Joel
Apr 22 2007
prev sibling parent reply 0ffh <spam frankhirsch.net> writes:
Xinok wrote:
 D only needs two things, though two very big things:
 1) A proper IDE
 2) Many more libraries
I second this, /especially/ the IDE! Just today I told a working colleague who talked about instead of MS-Java. First thing he asked: "Is there any proper IDE?". Of course I answered: "Who needs an IDE?", but that does not really solve the problem... Regards, Frank
Apr 23 2007
parent Dan <murpsoft hotmail.com> writes:
0ffh Wrote:

 Xinok wrote:
 D only needs two things, though two very big things:
 1) A proper IDE
 2) Many more libraries
I second this, /especially/ the IDE! Just today I told a working colleague who talked about instead of MS-Java. First thing he asked: "Is there any proper IDE?". Of course I answered: "Who needs an IDE?", but that does not really solve the problem... Regards, Frank
IDE? That's a more complicated Notepad++ or SciTE, isn't it? Last one I tried to use insisted I create a "project" before it would let me do anything. Then I tried to open my files, and it wouldn't let me compile them because it has some "project" issues. I fought with it for an hour, and then wondered if it was broken. I just wanted it to highlight source and let me use the menu to compile my fucking code. : p I've since extended SciTE to do exactly that. It would be nice to have a GUI profiler and debugger... right now I'm using the dmd command line ones.
Apr 23 2007
prev sibling next sibling parent reply Daniel Giddings <danielg microforte.com> writes:
If something like SWIG could generate glue code for D it would be a 
major boost for the language. Sure the produced bindings may not be the 
most efficient way of using a C++ library, but it would open a way for 
people to migrate towards D using existing C++ code and would make many 
libraries available with little effort.

janderson wrote:
 Its about time for another round of how D can conquer the world.
 
 The way I see it D has 2 options, provide an easy way for C++ users to 
 switch over or become D.net.  The problem is, it is extremely 
 impracticable to switch over to D because:
 
 1) Everything is already in C++.  It would take months to switch over. 
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There are 
 so many API's that companies use, it is impossible to have them all ported.
 3) Learning.  People are resistant to learning new things.  I think this 
 hurdle is easiest to jump if the other 2 are in place.
 
 The C++ option:
 
 There are several ways this could be done however all would be most 
 effective.
 
 1) Provide an easy way to link directly with C++ (preferably MSVC), such 
 that we can write in C++ an D simultaneously and without having to write 
 wrapper code.
 
 2) Provide a way to import C++ APIs that takes practically no time to 
 implement.
 
 3) Provide a wizard that will convert a C++ project to D.  It needs to 
 be so easy, you don't have to even think about it.
 
 This seems like its asking for a lot.  However a month or 2 was spent 
 setting up D so it could be integrated with C++ within a couple of 
 clicks, it would pay huge dividends.  This would mean that it would be 
 much easier for anyone at a C++ factory to convince managers of D's cost 
 befits.
 
 I think many C++ programmers are looking for a better alternative 
 however they can't switch to D because of the afore mentioned problems. 
  If this was done right, you could practically convert many of the C++ 
 community. Not unlike C++ did to C. I doubt you'll get many C converts 
 though because most of the ones remaining can't leave C for other reasons.
 
 
 D.Net option:
 

 D provides.  With products like XNA and a decent development 

 that works with net (that was in development ages ago), would give D a 
 foothold for the next generation of programmers.  I do however think 
 that D will be a harder sell on this platform.
 
 Final comments
 
 It may be possible for D to find its way into main stream by a nitch 
 market however I think the chances here are low.  Of course one possibly 
 here is the mobile phone industry.  Even so, D runs the risk of being a 
 one-time-wonder that is dependent on the phone companies continued support.
 
 Note that I discount Java because there is less overlap in 
 functionalities.  Furthermore note that my point of view is from the 
 game industry and the situation may be completely different for business.
 
 So if D wants to become big (say in the next year), I think some time 
 invested in supporting C++ is its best bet.
 
 -Joel
Apr 22 2007
next sibling parent Howard Berkey <howard well.com> writes:
bcd.gen does a reasonable job at generating bindings to C and C++ libraries:

http://www.dsource.org/projects/bcd

Howard


Daniel Giddings Wrote:

 If something like SWIG could generate glue code for D it would be a 
 major boost for the language. Sure the produced bindings may not be the 
 most efficient way of using a C++ library, but it would open a way for 
 people to migrate towards D using existing C++ code and would make many 
 libraries available with little effort.
 
 janderson wrote:
 Its about time for another round of how D can conquer the world.
 
 The way I see it D has 2 options, provide an easy way for C++ users to 
 switch over or become D.net.  The problem is, it is extremely 
 impracticable to switch over to D because:
 
 1) Everything is already in C++.  It would take months to switch over. 
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There are 
 so many API's that companies use, it is impossible to have them all ported.
 3) Learning.  People are resistant to learning new things.  I think this 
 hurdle is easiest to jump if the other 2 are in place.
 
 The C++ option:
 
 There are several ways this could be done however all would be most 
 effective.
 
 1) Provide an easy way to link directly with C++ (preferably MSVC), such 
 that we can write in C++ an D simultaneously and without having to write 
 wrapper code.
 
 2) Provide a way to import C++ APIs that takes practically no time to 
 implement.
 
 3) Provide a wizard that will convert a C++ project to D.  It needs to 
 be so easy, you don't have to even think about it.
 
 This seems like its asking for a lot.  However a month or 2 was spent 
 setting up D so it could be integrated with C++ within a couple of 
 clicks, it would pay huge dividends.  This would mean that it would be 
 much easier for anyone at a C++ factory to convince managers of D's cost 
 befits.
 
 I think many C++ programmers are looking for a better alternative 
 however they can't switch to D because of the afore mentioned problems. 
  If this was done right, you could practically convert many of the C++ 
 community. Not unlike C++ did to C. I doubt you'll get many C converts 
 though because most of the ones remaining can't leave C for other reasons.
 
 
 D.Net option:
 

 D provides.  With products like XNA and a decent development 

 that works with net (that was in development ages ago), would give D a 
 foothold for the next generation of programmers.  I do however think 
 that D will be a harder sell on this platform.
 
 Final comments
 
 It may be possible for D to find its way into main stream by a nitch 
 market however I think the chances here are low.  Of course one possibly 
 here is the mobile phone industry.  Even so, D runs the risk of being a 
 one-time-wonder that is dependent on the phone companies continued support.
 
 Note that I discount Java because there is less overlap in 
 functionalities.  Furthermore note that my point of view is from the 
 game industry and the situation may be completely different for business.
 
 So if D wants to become big (say in the next year), I think some time 
 invested in supporting C++ is its best bet.
 
 -Joel
Apr 22 2007
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Has everyone forgotten about bcd.gen?

http://www.dsource.org/projects/bcd/

  - Gregor Richards

(PS: No, it isn't complete. Templates rarely work. I haven't been 
actively working on it since people showed very little interest in it, 
and it had accomplished what I wanted it to)
Apr 22 2007
next sibling parent reply Daniel Giddings <danielg microforte.com> writes:
I'll give it a go - currently I'm wrapping up parts of Ogre (just 
playing around with it in D at the moment) - www.ogre3d.org.

It's not hard to do manually, but there is a lot of it.

:-) Dan

Gregor Richards wrote:
 Has everyone forgotten about bcd.gen?
 
 http://www.dsource.org/projects/bcd/
 
  - Gregor Richards
 
 (PS: No, it isn't complete. Templates rarely work. I haven't been 
 actively working on it since people showed very little interest in it, 
 and it had accomplished what I wanted it to)
Apr 22 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Giddings wrote:
 I'll give it a go - currently I'm wrapping up parts of Ogre (just 
 playing around with it in D at the moment) - www.ogre3d.org.
 
 It's not hard to do manually, but there is a lot of it.
 
 :-) Dan
 
Oooh. Are you the same person who was working on that before? There was a project called "Sinbad" on D source or somewhere. I seem to recall the guy behind that saying that Ogre didn't really lend itself to D so well. I forget why. Too many const references or something. Or maybe it was that he lost interest in using a C++-like API from D and wanted something more D-like. Anyway, hope your D/Ogre port goes well. Are you working off the Eihort release? Another engine that I'd like to be able to use from D is G3D. g3d-cpp.sourceforge.net. --bb
Apr 22 2007
parent reply Daniel Giddings <danielg microforte.com> writes:
Bill Baxter wrote:
 Oooh.  Are you the same person who was working on that before?   There
Nope. I quite like D for it as I typically use C++ for engine work and Python for game code, but with GC and other D features, D becomes quite attractive for game code as well.
 was a project called "Sinbad" on D source or somewhere.  I seem to 
 recall the guy behind that saying that Ogre didn't really lend itself to 
 D so well.  I forget why.  Too many const references or something.  Or 
 maybe it was that he lost interest in using a C++-like API from D and 
 wanted something more D-like.
I'm looking to make it largely usable for stuff I'm playing with so at the moment I'm not looking to bind all of it. I don't mind so much if I can't bind everything, just enough to manipulate objects in the world reasonably. At a lower level I'd make direct changes in C++ I think, or alter the API for difficult features through some intermediary C++ code with a C API. I've added SDL for windowing and input and ODE for physics. Once it is useable in a fashion I'll chuck it up somewhere. Currently I can load and place entities, affect them with physics and manipulate the camera.
 
 Anyway, hope your D/Ogre port goes well.  Are you working off the Eihort 
 release?
I'm working with an old release candidate of it I think, but I do want to use some of the new features.
 
 Another engine that I'd like to be able to use from D is G3D. 
 g3d-cpp.sourceforge.net.
 
 --bb
I haven't played with that one, so I'm not sure how it'd compare to Ogre. It does look interesting though. :-) Dan
Apr 22 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Giddings wrote:

 Another engine that I'd like to be able to use from D is G3D. 
 g3d-cpp.sourceforge.net.

 --bb
I haven't played with that one, so I'm not sure how it'd compare to Ogre. It does look interesting though.
To be honest I haven't used G3D that much either. But I keep intending to play with it. In contrast to Ogre which aims to be the all-in-one-everything-integrated-OO-engine, G3D is more a confederation of components you can build on. For example last time I used Ogre, there was no way to do immediate mode rendering. You just couldn't do it. You had to do all this mumbojumbo with their vertexbuffer interface and it was a real pain. Want to draw a quick bbox on the screen using lines, gotta go through the vertexbuffer interface. Yeh it's great for performance, but when you're prototyping or debugging you can afford to draw a few lines in immediate mode. G3D lets you start from raw OpenGL and build up from there. ... at least that's the way I understand it. Anyway, I know the guy who started G3D, and he's a smart cookie. So I suspect it's pretty decent. :-) --bb
Apr 23 2007
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Daniel Giddings wrote:
 I'll give it a go - currently I'm wrapping up parts of Ogre (just 
 playing around with it in D at the moment) - www.ogre3d.org.
 
 It's not hard to do manually, but there is a lot of it.
 
 :-) Dan
 
 Gregor Richards wrote:
 Has everyone forgotten about bcd.gen?

 http://www.dsource.org/projects/bcd/

  - Gregor Richards

 (PS: No, it isn't complete. Templates rarely work. I haven't been 
 actively working on it since people showed very little interest in it, 
 and it had accomplished what I wanted it to)
Ogre is very, very templatey. It's not even worth the attempt with the current state of bcd.gen. - Gregor Richards
Apr 22 2007
parent reply Dan <murpsoft hotmail.com> writes:
Gregor Richards Wrote:

 Daniel Giddings wrote:
 I'll give it a go - currently I'm wrapping up parts of Ogre (just 
 playing around with it in D at the moment) - www.ogre3d.org.
 
 It's not hard to do manually, but there is a lot of it.
 
 :-) Dan
 
 Gregor Richards wrote:
 Has everyone forgotten about bcd.gen?

 http://www.dsource.org/projects/bcd/

  - Gregor Richards

 (PS: No, it isn't complete. Templates rarely work. I haven't been 
 actively working on it since people showed very little interest in it, 
 and it had accomplished what I wanted it to)
Ogre is very, very templatey. It's not even worth the attempt with the current state of bcd.gen. - Gregor Richards
So what we really need then is to re-activate the BCD project and work out the bugs with the template system? You still interested in heading the project if you got some help Gregor? Polish it up a touch?
Apr 23 2007
parent Gregor Richards <Richards codu.org> writes:
Dan wrote:
 Gregor Richards Wrote:
 
 Daniel Giddings wrote:
 I'll give it a go - currently I'm wrapping up parts of Ogre (just 
 playing around with it in D at the moment) - www.ogre3d.org.

 It's not hard to do manually, but there is a lot of it.

 :-) Dan

 Gregor Richards wrote:
 Has everyone forgotten about bcd.gen?

 http://www.dsource.org/projects/bcd/

  - Gregor Richards

 (PS: No, it isn't complete. Templates rarely work. I haven't been 
 actively working on it since people showed very little interest in it, 
 and it had accomplished what I wanted it to)
Ogre is very, very templatey. It's not even worth the attempt with the current state of bcd.gen. - Gregor Richards
So what we really need then is to re-activate the BCD project and work out the bugs with the template system? You still interested in heading the project if you got some help Gregor? Polish it up a touch?
Sorry I didn't respond to this, I hate deeply-nested threads :) Sure. I still maintain bcd.gen, I just haven't made any changes because it does everything I need. If somebody wants to assist me in making it better, hooplah. - Gregor Richards
Apr 28 2007
prev sibling parent reply janderson <askme me.com> writes:
Gregor Richards wrote:
 Has everyone forgotten about bcd.gen?
 
 http://www.dsource.org/projects/bcd/
 
  - Gregor Richards
 
 (PS: No, it isn't complete. Templates rarely work. I haven't been 
 actively working on it since people showed very little interest in it, 
 and it had accomplished what I wanted it to)
I should acropolises, Gregor. I completely forgot about this. Its a good start for number 2). I still think that it needs to be so easy to use that people don't need to think. For instance being able to simply provide a visual studio project (and other popular IDEs) and have it convert it over to a D capable visual studio project, would help a lot. The final step would be either providing it on DMD or some sort of serious promotion on the D website. It sounds lazy but generally what gets people hooked. Also, I'm kinda confused why this project never gained much of a attention even in its current state? -Joel
Apr 23 2007
parent reply Alexander Panek <alexander.panek brainsware.org> writes:
On Mon, 23 Apr 2007 22:48:09 -0700
janderson <askme me.com> wrote:
 Also, I'm kinda confused why this project never gained much of a 
 attention even in its current state?
Well, I do tell anyone who joins #d and asks for bindings...so.. it's most likely an issue of too little advertisement media, or such. ;)
Apr 23 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Alexander Panek wrote:
 On Mon, 23 Apr 2007 22:48:09 -0700
 janderson <askme me.com> wrote:
 Also, I'm kinda confused why this project never gained much of a 
 attention even in its current state?
Well, I do tell anyone who joins #d and asks for bindings...so.. it's most likely an issue of too little advertisement media, or such. ;)
Maybe there just aren't that many folks with massive C APIs they want to wrap? Hmmm... maybe I could give it a try on the CBLAS/CLAPACK headers. I wrapped the Fortran BLAS/LAPACK libs directly using some crappy scripts I hacked up in Python. But maybe bcd.gen on the C ports would be a better way to go. For other stuff I've ported/wrapped, it's mostly been small enough to not be worth the effort of using an automated tool. --bb
Apr 23 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:
 Its about time for another round of how D can conquer the world.
 
 The way I see it D has 2 options, provide an easy way for C++ users to 
 switch over or become D.net.  The problem is, it is extremely 
 impracticable to switch over to D because:
 
 1) Everything is already in C++.  It would take months to switch over. 
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There are 
 so many API's that companies use, it is impossible to have them all ported.
 3) Learning.  People are resistant to learning new things.  I think this 
 hurdle is easiest to jump if the other 2 are in place.
 
 ...
 So if D wants to become big (say in the next year), I think some time 
 invested in supporting C++ is its best bet.
I don't think D needs to become big in the next year. If it got the easy ability to use C++ code (or Java code) directly, that may indeed help it take off. But I don't think it's necessary. I see D taking off in more the way of scripting languages like Python or Ruby. Python got introduced into companies by people who liked programming in it. I remember there was one guy in the company I worked for back in 1995 who used Python. And I was like Py what? What's wrong with Perl? But it grew slowly in popularity from humble beginnings, not because of huge financial backing, but because people in the trenches found it easy and *fun* to use. Today extensive libraries are one of the best things about Python. But I would guess back in 1995 the Python library collection was probably pretty weak. It grew because people liked using it and contributed things they needed. So, just give it time, and D will catch on. I've come back to programming D heavily for the past few days after an extended stay in Python land. And I have to say, I just really like D. Python is nice with it's dynamic everything, but there's something to be said for having a compiler that can tell you when you're referring to an undefined variable _before_ you spend 2 minutes running your program to the point where it executes the function you just added only to find that you typed "my_varible" instead of "my_variable". And Python is not without its warts. I'm always looking for ways to avoid making classes in my Python code because having to say 'self.avariable' and 'self.amethod' everywhere just gets really really annoying. I also find the lack of any notion of 'private' to be annoying. You need to be careful about what and how you import in a python module, because that all becomes part of the public interface for your module. You can prefix things with an underscore, but that's the other thing that annoys me about python. For a language with "clean" syntax, it sure does use a heck of a lot of underscore characters. Ahem. So anyway, D is cool. And I think it will catch on given time. The 1.0 release just came out. And 2.0 is shaping up to be the greatest thing that ever happened to programmer-kind. I think we're just seeing the beginning. On the other hand, if you want to write a C++ to D translator or automatic bridge or whatever to help accelerate the pace, I'm certainly not going to stop you. :-) --bb
Apr 22 2007
prev sibling next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
janderson wrote:
 Its about time for another round of how D can conquer the world.
 
 The way I see it D has 2 options, provide an easy way for C++ users to 
 switch over or become D.net.  The problem is, it is extremely 
 impracticable to switch over to D because:
 
 1) Everything is already in C++.  It would take months to switch over. 
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There are 
 so many API's that companies use, it is impossible to have them all ported.
 3) Learning.  People are resistant to learning new things.  I think this 
 hurdle is easiest to jump if the other 2 are in place.
 [...]
another Java, Scala is actually Java + FP, and a lot of people are starting to take notice. I don't see the future as being "more Java", even though that's where the industry is heading right now. I think that people are starting to realize that software reuse is an actual possibility, despite the failed promises of the OOP revolution; but that reuse really needs full genericity to be implemented usefully (and no, I don't mean Java-style genericity). want something so simple their trench coders couldn't possibly screw it up. Scala aims to be an academic language, which is fine for theorists trying to show that it is possible to make an FP language as useful as Java. D, I think, aims somewhere in the middle, giving users the nuts and bolts and simplicity of a good industrial language (especially ones which many of them are already familiar with), while also providing some pretty nasty high-level academic tricks that library authors can take advantage of. However, D is just now getting these high-level features, so I think it will take some time for them to manifest and demonstrate their utility. It seems that a lot of these features are starting to become mainstream, so I think D is well-positioned to take advantage of this trend. For people to appreciate the power of a new language, there needs to be programmers who understand what it can do well enough to illustrate that power. I think the academic concepts that were mostly relegated to FP langs now have enough users that at least the high-end library writers are demanding these features in languages, making it possible for advanced languages to enjoy a more mainstream audience. I think what even FP langs have not explored to a compelling level of detail is metaprogramming. I get the impression that most FP programmers feel that higher-order functions are good enough, and even Lisp "just has macros". But I think D will show that while macros are powerful, they are not a replacement for templates and do not cover the full space of metaprogramming. Yes, it is possible to do non-macro metaprogramming in Lisp, but being a dynamically checked language, this isn't nearly as interesting as it is in D. On some level, I agree that "It's the Library, Stupid!" (to paraphrase a former President). However, I disagree that it's *just* the library...I think it is how the library is constructed. I think the next revolution in software engineering will be highly configurable and extensible libraries, which will tend to obsolete the large collections of redundant libraries we have today. Because designing a highly configurable library is fundamentally different from designing a concrete library, I don't think there is much to be gained by simply making every C++ or C or X library available in D. I think the true power of D will be manifested when plain ol' libraries with canonical implementations get redesigned as generic libraries which are both fast and powerful. I think projects like Tango and TioPort are good, because these foundational services are necessary for bootstrapping. And I don't think copying the STL to make the DTL was the right way to go. D offers metaprogramming facilities far and above what C++ allows. The true power of D will become apparent when DTL is resurrected with the full power of D's metaprogramming system brought to bear. Anyway, that's just my 2c. Dave
Apr 23 2007
next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Mon, 23 Apr 2007 13:28:56 +0400, David B. Held  
<dheld codelogicconsulting.com> wrote:

 I think what even FP langs have not explored to a compelling level of  
 detail is metaprogramming.  I get the impression that most FP  
 programmers feel that higher-order functions are good enough, and even  
 Lisp "just has macros".  But I think D will show that while macros are  
 powerful, they are not a replacement for templates and do not cover the  
 full space of metaprogramming.  Yes, it is possible to do non-macro  
 metaprogramming in Lisp, but being a dynamically checked language, this  
 isn't nearly as interesting as it is in D.
I'm afraid that D will lose the competition to Nemerle in such area. Because Nemerle is FP language and is based on metaprogramming. Nemerle has very small FP-core of language and everything else is implemented via macros (even if- and for-statements are macros in Nemerle). Unlike Lisp Nemerle is a statically typed languages, it has generics too. And Nemerle is .Net language, so it already has a big amount of avialable libraries. -- Regards, Yauheni Akhotnikau
Apr 23 2007
parent reply Don Clugston <dac nospam.com.au> writes:
eao197 wrote:
 On Mon, 23 Apr 2007 13:28:56 +0400, David B. Held 
 <dheld codelogicconsulting.com> wrote:
 
 I think what even FP langs have not explored to a compelling level of 
 detail is metaprogramming.  I get the impression that most FP 
 programmers feel that higher-order functions are good enough, and even 
 Lisp "just has macros".  But I think D will show that while macros are 
 powerful, they are not a replacement for templates and do not cover 
 the full space of metaprogramming.  Yes, it is possible to do 
 non-macro metaprogramming in Lisp, but being a dynamically checked 
 language, this isn't nearly as interesting as it is in D.
I'm afraid that D will lose the competition to Nemerle in such area.
Don't bet on it. It's not clear to me that there will be much of use that Nemerle can do, which D will not be able to, once it has macros. The question is, how well does metaprogramming scale in each of these languages? Pages like this one: http://nemerle.org/Defining_types_from_inside_macros gives me grave doubts about Nemerle. Reading all those macro pages, the whole thing seems like a hack, that exposes many low-level details of the compiler. But obviously, the language may improve with time.
 Because Nemerle is FP language and is based on metaprogramming. Nemerle 
 has very small FP-core of language and everything else is implemented 
 via macros (even if- and for-statements are macros in Nemerle). Unlike 
 Lisp Nemerle is a statically typed languages, it has generics too. And 
 Nemerle is .Net language, so it already has a big amount of avialable 
 libraries.
 
 --Regards,
 Yauheni Akhotnikau
Apr 23 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Mon, 23 Apr 2007 16:02:33 +0400, Don Clugston <dac nospam.com.au> wro=
te:

 Don't bet on it. It's not clear to me that there will be much of use  =
 that Nemerle can do, which D will not be able to, once it has macros.
It is not clean to me what kind of macro subsystem D will have. Because = of = that I can't do any prediction. Big Nemerle lobby exists on the Russian programmer's resource RSDN.ru. A= nd = people from it sometimes point to interesting example of Nemerle macro = usages. For example = 75): def m1 =3D Cgs.Mass(1); def m2 =3D Si.Mass(m1); WriteLine($"Mass in SI: $m2, in CGS: $m1"); It is sample of string interpolation, when string literal is parsed in = compile-time and variables marked by $ are type-safely converted into = string. And this is an example of "physical literals": def x1 =3D Si.Area(1 cm * 10 m); where modifiers 'cm' and 'm' implemented via macros.
 The question is, how well does metaprogramming scale in each of these =
=
 languages?
I don't understand what you meen with 'scale'. I think there is another threat for Nemerle -- it is so easy to create = their own mini-language with Nemerle syntax macros -- that would lead to= = incompatible solution for some problem from different programmers. = Moreover different macro libs may introduce the same keywords into = language -- that make impossible to use them together. But Nemerle fans = = say that is not a problem :)
 Pages like this one:
 http://nemerle.org/Defining_types_from_inside_macros
 gives me grave doubts about Nemerle. Reading all those macro pages, th=
e =
 whole thing seems like a hack, that exposes many low-level details of =
=
 the compiler. But obviously, the language may improve with time.
Yes, macro code looks very ugly at the first sight. But this is true onl= y = when you have no enough knowledge of the language. With time macro code = = could be read without big problems. The same situation exists even with compile-time code in D :) -- = Regards, Yauheni Akhotnikau
Apr 23 2007
parent reply Georg Wrede <georg nospam.org> writes:
eao197 wrote:
 Don Clugston <dac nospam.com.au> wrote:
 The question is, how well does metaprogramming scale in each of these  
 languages?
I don't understand what you meen with 'scale'.
Scale means: you can do the same thing if your program is small and if it is big. For example, procedural programming is good for small programs, but for a 1 million line application, procedural is not good. There you need OO or something else.
Apr 23 2007
next sibling parent 0ffh <spam frankhirsch.net> writes:
Georg Wrede wrote:
 Scale means: you can do the same thing if your program is small and if 
 it is big.
 
 For example, procedural programming is good for small programs, but for 
 a 1 million line application, procedural is not good. There you need OO 
 or something else.
I'd rather say it depends on the kind of application rather than sheer LOC. (Admittedly, monster projects that produce millions of LOC are often of the kind where OO actually /is/ a good idea, for a given meaning of OO.) Regards, Frank
Apr 23 2007
prev sibling parent reply eao197 <eao197 intervale.ru> writes:
On Tue, 24 Apr 2007 03:25:48 +0400, Georg Wrede <georg nospam.org> wrote:

 eao197 wrote:
 Don Clugston <dac nospam.com.au> wrote:
 The question is, how well does metaprogramming scale in each of these   
 languages?
I don't understand what you meen with 'scale'.
Scale means: you can do the same thing if your program is small and if it is big.
There is another sence of 'scale': can a project with intensive use of macros be manageable and maintainable if the project team has one, two,..., ten,..., a hundred or more programmers. AFAIK, Lisp proves that languages with high degree of metaprogramming don't scale well in that sence. Because every developer tends to invent his own, more powerful and elegant Lisp [http://www.c2.com/cgi/wiki?SocialProblemsOfLisp ;)]. -- Regards, Yauheni Akhotnikau
Apr 23 2007
parent reply Don Clugston <dac nospam.com.au> writes:
eao197 wrote:
 On Tue, 24 Apr 2007 03:25:48 +0400, Georg Wrede <georg nospam.org> wrote:
 
 eao197 wrote:
 Don Clugston <dac nospam.com.au> wrote:
 The question is, how well does metaprogramming scale in each of 
 these  languages?
I don't understand what you meen with 'scale'.
Scale means: you can do the same thing if your program is small and if it is big.
There is another sence of 'scale': can a project with intensive use of macros be manageable and maintainable if the project team has one, two,..., ten,..., a hundred or more programmers.
I meant both senses -- a ten-line program is not going to have a hundred programmers working on it. I don't think we know yet how well either D or Nermele will scale; but my intuition that D will fare better.
 AFAIK, Lisp proves that languages with high degree of metaprogramming 
 don't scale well in that sence. Because every developer tends to invent 
 his own, more powerful and elegant Lisp 
 [http://www.c2.com/cgi/wiki?SocialProblemsOfLisp ;)].
I think Nemerle will suffer from this. IMHO, being able to define 'for' in the language itself, has no benefit in practice; the set of useful control constructs is very well known. If it's useful to everyone, it should be rigidly controlled by the language; otherwise you get confusion and incompatibility. I suspect that in D, metaprogramming will be used almost exclusively for domain-specific languages.
Apr 23 2007
next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Tue, 24 Apr 2007 10:40:48 +0400, Don Clugston <dac nospam.com.au> wrote:

 I don't think we know yet how well either D or Nermele will scale; but  
 my intuition that D will fare better.
I agree with you.
 AFAIK, Lisp proves that languages with high degree of metaprogramming  
 don't scale well in that sence. Because every developer tends to invent  
 his own, more powerful and elegant Lisp  
 [http://www.c2.com/cgi/wiki?SocialProblemsOfLisp ;)].
I think Nemerle will suffer from this. IMHO, being able to define 'for' in the language itself, has no benefit in practice; the set of useful control constructs is very well known. If it's useful to everyone, it should be rigidly controlled by the language; otherwise you get confusion and incompatibility.
Implementation of 'for' as macro is just an example. Main constructs are already in language and nobody will reimplement it. But macro system in Nemerle allows to insert a DSL with different syntax into a program by extending core language syntax. In my opinion that is more a problem that a benefit, especially in long-term projects with big or/and highly rotated teams. But my point was: because of nature of Nemerle it is very hard to compete with it in metaprogramming area.
 I suspect that in D, metaprogramming will be used almost exclusively for  
 domain-specific languages.
I agree with you here again. But it is hard to make any prediction without knowledge of the future D macro system. -- Regards, Yauheni Akhotnikau
Apr 24 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
eao197 wrote:

 But my point was: because of nature of Nemerle it is very hard to 
 compete with it in metaprogramming area.
But fortunately Nemerle is very easy to compete with in areas such as "compiling to native binaries" and "working cross-platform" and "generating native code" and "writing device drivers". :-) --bb
Apr 24 2007
parent eao197 <eao197 intervale.ru> writes:
On Tue, 24 Apr 2007 11:35:17 +0400, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:

 But my point was: because of nature of Nemerle it is very hard to  
 compete with it in metaprogramming area.
But fortunately Nemerle is very easy to compete with in areas such as "compiling to native binaries" and "working cross-platform" and "generating native code" and "writing device drivers". :-)
Only with two of them: "compiling to native binaries" and "writing device drives" :) Because Nemerle is developing mainly on Linux and Mono ("working cross-platform") and AFAIK, MSIL compiled into native code by JIT at the first run ("generating native code"). And on MS .Net implementation Nemerle has a very good garbage collector. But D is competitive with Nemerle because Nemerle is .Net based language. So it would have good run-time system only on MS platforms. AFAIK, Mono is not 100% compatible with MS .Net, so writing cross-platform programs in .Net languages will be a hard task. I think the major concurent of D in cross-platform development should be Java, not .Net. -- Regards, Yauheni Akhotnikau
Apr 24 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:
 I think Nemerle will suffer from this. IMHO, being able to define 'for' 
 in the language itself, has no benefit in practice; the set of useful 
 control constructs is very well known. If it's useful to everyone, it 
 should be rigidly controlled by the language; otherwise you get 
 confusion and incompatibility.
 I suspect that in D, metaprogramming will be used almost exclusively for 
 domain-specific languages.
I agree that too much flexibility in a language is a bad thing. Imagine if you could redefine everything in D. Taken to the limit, that means that every random sequence of characters could be a valid program! This is just not useful. C++ suffers from this problem somewhat with the preprocessor. The problem is recognized, and C++ programs that do things like: #define BEGIN { #define END } are frowned upon. Back in the 80's when people wrote a lot of assembler, MASM had a fairly powerful preprocessor. Lots of people essentially invented their own languages, that preprocessed down to assembler. Microsoft shipped one of these as an include file with MASM. Lots of people found it impenetrable. A friend of mine had a lot of difficulty with it, and finally resolved the problems by assembling the code with MASM, running OBJ2ASM on the result, and then using OBJ2ASM's output as his new source code. *Then* he understood what was going on <g>. A language needs to have common reference points, some reliable touchstones that people can look at and say "I understand that". It's why D, for example, has the debug statements. Sure, you can do the same thing with version and other constructs. But if you've managed C++ code for a while, everybody comes up with a different way of doing #ifdef DEBUG, all different, but all functionally about the same. It just causes problems when combining projects. So by wiring a debug statement in to the compiler, one encourages a common way of doing the common task. The same goes for unit tests.
Apr 24 2007
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:
 Don Clugston wrote:
 I think Nemerle will suffer from this. IMHO, being able to define 
 'for' in the language itself, has no benefit in practice; the set of 
 useful control constructs is very well known. If it's useful to 
 everyone, it should be rigidly controlled by the language; otherwise 
 you get confusion and incompatibility.
 I suspect that in D, metaprogramming will be used almost exclusively 
 for domain-specific languages.
I agree that too much flexibility in a language is a bad thing. Imagine if you could redefine everything in D. Taken to the limit, that means that every random sequence of characters could be a valid program! This is just not useful. C++ suffers from this problem somewhat with the preprocessor. The problem is recognized, and C++ programs that do things like: #define BEGIN { #define END } are frowned upon. Back in the 80's when people wrote a lot of assembler, MASM had a fairly powerful preprocessor. Lots of people essentially invented their own languages, that preprocessed down to assembler. Microsoft shipped one of these as an include file with MASM. Lots of people found it impenetrable. A friend of mine had a lot of difficulty with it, and finally resolved the problems by assembling the code with MASM, running OBJ2ASM on the result, and then using OBJ2ASM's output as his new source code. *Then* he understood what was going on <g>. A language needs to have common reference points, some reliable touchstones that people can look at and say "I understand that". It's why D, for example, has the debug statements. Sure, you can do the same thing with version and other constructs. But if you've managed C++ code for a while, everybody comes up with a different way of doing #ifdef DEBUG, all different, but all functionally about the same. It just causes problems when combining projects. So by wiring a debug statement in to the compiler, one encourages a common way of doing the common task. The same goes for unit tests.
Amen. Oh and on a side note... THANK YOU for designing those 'debug' statements so that they can have IDENTIFIERS as triggers. Its a rare occasion that I can make much use of 'debug level 1 or 2' over 'debug of Foo or Bar'. Same with 'version'. Otherwise, I imagine we would've all invented our own modules full of enums for the sole purpose of flagging version/debug statements. -- Chris Nicholson-Sauls
Apr 24 2007
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright Wrote:

 Don Clugston wrote:
 I think Nemerle will suffer from this. IMHO, being able to define 'for' 
 in the language itself, has no benefit in practice; the set of useful 
 control constructs is very well known. If it's useful to everyone, it 
 should be rigidly controlled by the language; otherwise you get 
 confusion and incompatibility.
 I suspect that in D, metaprogramming will be used almost exclusively for 
 domain-specific languages.
I agree that too much flexibility in a language is a bad thing. Imagine if you could redefine everything in D. Taken to the limit, that means that every random sequence of characters could be a valid program! This is just not useful. C++ suffers from this problem somewhat with the preprocessor. The problem is recognized, and C++ programs that do things like: #define BEGIN { #define END } are frowned upon. Back in the 80's when people wrote a lot of assembler, MASM had a fairly powerful preprocessor. Lots of people essentially invented their own languages, that preprocessed down to assembler. Microsoft shipped one of these as an include file with MASM. Lots of people found it impenetrable. A friend of mine had a lot of difficulty with it, and finally resolved the problems by assembling the code with MASM, running OBJ2ASM on the result, and then using OBJ2ASM's output as his new source code. *Then* he understood what was going on <g>. A language needs to have common reference points, some reliable touchstones that people can look at and say "I understand that". It's why D, for example, has the debug statements. Sure, you can do the same thing with version and other constructs. But if you've managed C++ code for a while, everybody comes up with a different way of doing #ifdef DEBUG, all different, but all functionally about the same. It just causes problems when combining projects. So by wiring a debug statement in to the compiler, one encourages a common way of doing the common task. The same goes for unit tests.
So, no obfuscated D code contest?
Apr 24 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 Back in the 80's when people wrote a lot of assembler, MASM had a fairly 
 powerful preprocessor. Lots of people essentially invented their own 
 languages, that preprocessed down to assembler. Microsoft shipped one of 
 these as an include file with MASM.
 
 Lots of people found it impenetrable. A friend of mine had a lot of 
 difficulty with it, and finally resolved the problems by assembling the 
 code with MASM, running OBJ2ASM on the result, and then using OBJ2ASM's 
 output as his new source code. *Then* he understood what was going on <g>.
I'll admit that this is why I'm not a huge fan of Randy Hyde's "High Level Assembly." I picked up his book as a way to learn x86 ASM (having only done 68000 ASM in the past), and the HLA abstraction just confused things for me. I ended up grabbing the Intel IA-32 docs and reading those instead. Sean
Apr 25 2007
prev sibling parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 25 Apr 2007 02:26:48 +0400, Walter Bright  =

<newshound1 digitalmars.com> wrote:

 Don Clugston wrote:
 I think Nemerle will suffer from this. IMHO, being able to define 'fo=
r' =
 in the language itself, has no benefit in practice; the set of useful=
=
 control constructs is very well known. If it's useful to everyone, it=
=
 should be rigidly controlled by the language; otherwise you get  =
 confusion and incompatibility.
 I suspect that in D, metaprogramming will be used almost exclusively =
=
 for domain-specific languages.
I agree that too much flexibility in a language is a bad thing. Imagin=
e =
 if you could redefine everything in D. Taken to the limit, that means =
=
 that every random sequence of characters could be a valid program! Thi=
s =
 is just not useful.
I'm affraid there is some point of misunderstanding of possible usages o= f = metaprograming in languages like Nemerle. Just take DSL as example. = Nemerle allows to include DSL with different syntax into ordinary Nemerl= e = program. For example try to imagine inclusion of ASN.1 fragment[1] into = = code: ASN1 class OrderForStock ::=3D SEQUENCE { order-no INTEGER, name-address BranchIdentification, details SEQUENCE OF SEQUENCE { item OBJECT IDENTIFIER, cases INTEGER }, urgency ENUMERATED { tomorrow(0), three-day(1), week(2) } DEFAULT week, authenticator Security-Type } where 'ASN1' is start of Nemerle syntax macro**. This is not far away from using CTFE and mixin in the current D version,= = for example: mixin(Asn1Class( ` OrderForStock ::=3D SEQUENCE { order-no INTEGER, name-address BranchIdentification, details SEQUENCE OF SEQUENCE { item OBJECT IDENTIFIER, cases INTEGER }, urgency ENUMERATED { tomorrow(0), three-day(1), week(2) } DEFAULT week, authenticator Security-Type }` ) ) But Nemerle allow to use all power of language in macro processing (for = = example it is possible to open and read files in compile-time, connect a= nd = gather information from remote servers (for WSDL processing and etc), = retrieving DB schemas, loading precalculated data from somewhere). What D can answer to that power? Or may be ASN.1 is not a DSL for which D's mixin is meant for? [1] An example from John Larmouth "ASN.1 Complete" = (http://www.c7.com/ss7/books/ASN1_Complete.pdf, page 48) ** I don't know could it be written exactly that way, may be it would be= = necessary to enclose some part of it into quotes. -- = Regards, Yauheni Akhotnikau
Apr 25 2007
parent reply =?KOI8-R?Q?Jari-Matti_Ma=22kela=22?= <jmjmak utu.fi.invalid> writes:
eao197 wrote:

 I'm affraid there is some point of misunderstanding of possible usages
 of metaprograming in languages like Nemerle. Just take DSL as example.
 Nemerle allows to include DSL with different syntax into ordinary
 Nemerle program. For example try to imagine inclusion of ASN.1
 fragment[1] into code:
 
     ASN1 class OrderForStock ::= SEQUENCE {
       order-no INTEGER,
       name-address BranchIdentification,
       details SEQUENCE OF SEQUENCE {
          item OBJECT IDENTIFIER,
          cases INTEGER },
       urgency ENUMERATED {
          tomorrow(0),
          three-day(1),
          week(2)
       } DEFAULT week,
       authenticator Security-Type
     }
 
 where 'ASN1' is start of Nemerle syntax macro**.
 
 But Nemerle allow to use all power of language in macro processing
Does it offer builtin facilities for parsing the macro code, if it's of some unknown syntax or does it set some limits to the syntax? Or is it handled as a string as in D?
(for example it is possible to open and read files in compile-time,
Well, this is possible in D now too.
 Or may be ASN.1 is not a DSL for which D's mixin is meant for?
No, this is exactly the kind of DSL I would like to see embedded in programs written in D.
Apr 25 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 25 Apr 2007 23:23:52 +0400, "Jari-Matti Ma"kela""  
<jmjmak utu.fi.invalid> wrote:

 But Nemerle allow to use all power of language in macro processing
Does it offer builtin facilities for parsing the macro code, if it's of some unknown syntax or does it set some limits to the syntax? Or is it handled as a string as in D?
It has a 'syntax macro' which allow some kind of syntax extension[1, 2]. But I'm not an Nemerle programmer, so it is hard to me to give details. It seems that there are some limitation, but it is possible to present some 'hard' fragments as a strings or fragments in special quotes (like (), {}, [], <[]> and so on). [1] http://nemerle.org/Features#New_language_constructs [2] http://nemerle.org/Syntax_extensions
 (for example it is possible to open and read files in compile-time,
 Well, this is possible in D now too.
May be I miss something. How to do this in D in compile-time? -- Regards, Yauheni Akhotnikau
Apr 25 2007
parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
eao197 wrote:
 On Wed, 25 Apr 2007 23:23:52 +0400, "Jari-Matti Ma"kela""
 (for example it is possible to open and read files in compile-time,
 Well, this is possible in D now too.
May be I miss something. How to do this in D in compile-time?
It doesn't implement full I/O, but you can do some stuff with import expressions. Some operating systems (Plan9) are heavily file oriented so it can help a lot. Of course importing regular files is possible in other systems too. Was this what you were looking for?
 
 --Regards,
 Yauheni Akhotnikau
Apr 25 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 26 Apr 2007 00:12:19 +0400, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:

 eao197 wrote:
 On Wed, 25 Apr 2007 23:23:52 +0400, "Jari-Matti Ma"kela""
 (for example it is possible to open and read files in compile-time,
 Well, this is possible in D now too.
May be I miss something. How to do this in D in compile-time?
It doesn't implement full I/O, but you can do some stuff with import expressions. Some operating systems (Plan9) are heavily file oriented so it can help a lot. Of course importing regular files is possible in other systems too. Was this what you were looking for?
I know about the import expression, but I speak about different kind of file processing. For example: 1) open a x.503 certificate file during compilation, checking it and importing a public key from it into a program as byte array; 2) open a WSDL file, parsing it and generating stubs or skeletons for the described WebService; and so on. I think I need to describe my own point of view. There isn't need to support such DSL via some special language features (like more powerful CTFE or syntax extension). All these tasks can be done by external code generation tools and the import expression is enough. But external code generation has its own drawbacks. It needs external software installed, it cannot be used in foreign compile farms (or usage may be limited), it needs more advanced build tools. However there are other kinds of DSL which require more advanced CTFE and, may be, some macro system (like samples from Don Clugston). At now I just want to understand what kinds of DSL can be handled by different techniques (CTFE and mixins, macros, external code generation and so on). -- Regards, Yauheni Akhotnikau
Apr 25 2007
parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
eao197 kirjoitti:
 On Thu, 26 Apr 2007 00:12:19 +0400, Jari-Matti Mäkelä
 <jmjmak utu.fi.invalid> wrote:
 
 eao197 wrote:
 On Wed, 25 Apr 2007 23:23:52 +0400, "Jari-Matti Ma"kela""
 (for example it is possible to open and read files in compile-time,
 Well, this is possible in D now too.
May be I miss something. How to do this in D in compile-time?
It doesn't implement full I/O, but you can do some stuff with import expressions. Some operating systems (Plan9) are heavily file oriented so it can help a lot. Of course importing regular files is possible in other systems too. Was this what you were looking for?
I know about the import expression, but I speak about different kind of file processing. For example: 1) open a x.503 certificate file during compilation, checking it and importing a public key from it into a program as byte array; 2) open a WSDL file, parsing it and generating stubs or skeletons for the described WebService; and so on.
 I think I need to describe my own point of view. There isn't need to
 support such DSL via some special language features (like more powerful
 CTFE or syntax extension). All these tasks can be done by external code
 generation tools and the import expression is enough.
 
 But external code generation has its own drawbacks. It needs external
 software installed, it cannot be used in foreign compile farms (or usage
 may be limited), it needs more advanced build tools.
 
 However there are other kinds of DSL which require more advanced CTFE
 and, may be, some macro system (like samples from Don Clugston).
 
 At now I just want to understand what kinds of DSL can be handled by
 different techniques (CTFE and mixins, macros, external code generation
 and so on).
 
Yeah, I follow you. Simple text imports can be done with the import expression, but if you need more processing functionality, it can be done with D without need for external tools. Actually it's quite simple, you just need to create a custom parser for a DSL. Something like const char[] file = "foo.bar"; char[] parseX503File(char[] data) { return data[1..$-1]; // or something more interesting } const certificate = parseX503File(import(file)); void main() { setServerCertificate(certificate); } This could be done with much cleaner code too, but DMD has now several bugs in type inference. CTFE and templates are already Turing complete so you won't get much more with additional macro features. They can only simplify the syntax and common idioms. But yes, it has been exciting following the evolution of metaprogramming features in D. I really don't know what's ahead, hopefully something that makes EDSLs a piece of cake for everyday coders.
 --Regards,
 Yauheni Akhotnikau
Apr 25 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 26 Apr 2007 02:00:44 +0400, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:

Excuse me, I made a mistake: x.509 certificate, not x.503 (see  
http://en.wikipedia.org/wiki/X.509)

 At now I just want to understand what kinds of DSL can be handled by
 different techniques (CTFE and mixins, macros, external code generation
 and so on).
Yeah, I follow you. Simple text imports can be done with the import expression, but if you need more processing functionality, it can be done with D without need for external tools. Actually it's quite simple, you just need to create a custom parser for a DSL. Something like const char[] file = "foo.bar"; char[] parseX503File(char[] data) { return data[1..$-1]; // or something more interesting } const certificate = parseX503File(import(file)); void main() { setServerCertificate(certificate); }
Unfortunately parsing X509 certificates can be very tired task because it is necessary to handle ASN.1 data structures, byte ordering, calculating digital signatures and so on. Do you want to implement MD5, SHA1 or SHA256 via CTFE and templates? :) However, Tango already has necessary classes which can significaly simplify the task of parsing X509 certificates (tango.transform.digest.*, tango.io.protocol.* and so on). And yet more it is possible to wrap OpenSSL into D library and use very powerful tool for handling certificates. It would be great if ordinary D code/libraries/wrappers-for-C-libraries can be used in compile-time. But I don't know how it can be done in D. As I've said previously it is not necessary at all, because we can use external code generation. Another interesting idea which can be used for some kind of DSL (especially in Don Clugston's computation examples) is a staged compilation. For example see Jumbo project for Java: http://loome.cs.uiuc.edu/Jumbo/
 This could be done with much cleaner code too, but DMD has now several
 bugs in type inference.

 CTFE and templates are already Turing complete so you won't get much
 more with additional macro features.
It is said that C++ templates are Turing complete too :)) -- Regards, Yauheni Akhotnikau
Apr 25 2007
parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
eao197 wrote:

 Unfortunately parsing X509 certificates can be very tired task because
 it is necessary to handle ASN.1 data structures, byte ordering,
 calculating digital signatures and so on. Do you want to implement MD5,
 SHA1 or SHA256 via CTFE and templates? :)
No :), I was just pointing out that you can do this with D too. I'm not sure how much better Nemerle would do.
 It would be great if ordinary D code/libraries/wrappers-for-C-libraries
 can be used in compile-time. But I don't know how it can be done in D.
 As I've said previously it is not necessary at all, because we can use
 external code generation.
Just follow the restrictions CTFE has, then you can basically run any algorithm as if it was run at runtime. It does not allow running C code because of the linking phase and library dependencies, but porting the code would not be a problem. Interpreting metaprograms is so much slower than running separate tools that I would probably keep them separate if possible unless there are some other benefits.
 Another interesting idea which can be used for some kind of DSL
 (especially in Don Clugston's computation examples) is a staged
 compilation. For example see Jumbo project for Java:
 http://loome.cs.uiuc.edu/Jumbo/
This is very much like templates, but with a special preprocessor syntax. I didn't read it all yet, but it looks interesting. I wonder why hasn't it gained much popularity.
 CTFE and templates are already Turing complete so you won't get much
 more with additional macro features.
It is said that C++ templates are Turing complete too :))
Will you excuse me while I go puke... :P No, seriously, CTFE is something totally different from C++ templates in terms of usability.
Apr 26 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 26 Apr 2007 15:31:57 +0400, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:

 Unfortunately parsing X509 certificates can be very tired task because
 it is necessary to handle ASN.1 data structures, byte ordering,
 calculating digital signatures and so on. Do you want to implement MD5,
 SHA1 or SHA256 via CTFE and templates? :)
No :), I was just pointing out that you can do this with D too. I'm not sure how much better Nemerle would do.
Nemerle allows to call code from any library at compile time.
 No, seriously, CTFE is
 something totally different from C++ templates in terms of usability.
Fully agree with you here. -- Regards, Yauheni Akhotnikau
Apr 26 2007
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
eao197 wrote:
 On Thu, 26 Apr 2007 15:31:57 +0400, Jari-Matti Mäkelä
 <jmjmak utu.fi.invalid> wrote:
 
 Unfortunately parsing X509 certificates can be very tired task because
 it is necessary to handle ASN.1 data structures, byte ordering,
 calculating digital signatures and so on. Do you want to implement MD5,
 SHA1 or SHA256 via CTFE and templates? :)
No :), I was just pointing out that you can do this with D too. I'm not sure how much better Nemerle would do.
Nemerle allows to call code from any library at compile time.
IIRC, this is because Nemerle takes the macros, compiles them to a library, loads that library and then hooks it into the compiler. Nemerle's macros are basically full and complete libraries that get run like normal code, so there's no reason they *shouldn't* use other libraries. D on the other hand does CTFE via an extension to constant-folding, so it is much more limited than Nemerle's approach. Nemerle is doing a full meta compile, link & execution stage, whilst D is just doing symbolic manipulation (kinda). On the other hand, I don't think Nemerle can run unmodified functions at compile time, or do all the cool tricks we can with templates. You win some, you lose some :)
 No, seriously, CTFE is
 something totally different from C++ templates in terms of usability.
Fully agree with you here. --Regards, Yauheni Akhotnikau
-- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Apr 26 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
eao197 wrote:
 On Thu, 26 Apr 2007 15:31:57 +0400, Jari-Matti Mäkelä 
 <jmjmak utu.fi.invalid> wrote:
 
 Unfortunately parsing X509 certificates can be very tired task because
 it is necessary to handle ASN.1 data structures, byte ordering,
 calculating digital signatures and so on. Do you want to implement MD5,
 SHA1 or SHA256 via CTFE and templates? :)
No :), I was just pointing out that you can do this with D too. I'm not sure how much better Nemerle would do.
Nemerle allows to call code from any library at compile time.
Wow. Would this let you implement a text-only virus (during compilation, secretly duplicates itself into the source code of all your other Nemerle projects)?
 
 No, seriously, CTFE is
 something totally different from C++ templates in terms of usability.
Fully agree with you here. --Regards, Yauheni Akhotnikau
Apr 26 2007
next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 26 Apr 2007 17:39:11 +0400, Don Clugston <dac nospam.com.au> wrote:

 No :), I was just pointing out that you can do this with D too. I'm not
 sure how much better Nemerle would do.
Nemerle allows to call code from any library at compile time.
Wow. Would this let you implement a text-only virus (during compilation, secretly duplicates itself into the source code of all your other Nemerle projects)?
May be. I'm not a Nemerle programmer so I can't say more precisely. But when I use some third party tool (something like IDL translator or ASN.1 compiler, or even lib.exe from DMD distribution) that tool can secretly modify my D projects ;) Or may be something like that can take place when I'm configuring some Unix project via './configure' :)) -- Regards, Yauheni Akhotnikau
Apr 26 2007
parent reply Dan <murpsoft hotmail.com> writes:
eao197 Wrote:

 On Thu, 26 Apr 2007 17:39:11 +0400, Don Clugston <dac nospam.com.au> wrote:
 
 No :), I was just pointing out that you can do this with D too. I'm not
 sure how much better Nemerle would do.
Nemerle allows to call code from any library at compile time.
Wow. Would this let you implement a text-only virus (during compilation, secretly duplicates itself into the source code of all your other Nemerle projects)?
May be. I'm not a Nemerle programmer so I can't say more precisely. But when I use some third party tool (something like IDL translator or ASN.1 compiler, or even lib.exe from DMD distribution) that tool can secretly modify my D projects ;) Or may be something like that can take place when I'm configuring some Unix project via './configure' :)) -- Regards, Yauheni Akhotnikau
Frightening. Especially with all these massive project people like to make where obscuring such a virus would be easy. Good thing I don't use such projects. "I don't understand how it's possible to both use more than 10,000 lines of high level code, and solve a problem in the same program" - me
Apr 26 2007
parent Alexander Panek <alexander.panek brainsware.org> writes:
On Thu, 26 Apr 2007 11:52:20 -0400
Dan <murpsoft hotmail.com> wrote:
 [...]
 "I don't understand how it's possible to both use more than 10,000
 lines of high level code, and solve a problem in the same program"
Ha.. I argued with my colleague at school, with whom I work[ed] on my diploma project, and he was totally weirded out by the fact, that I've written only about 500-600 lines of code in our library, over half a year. OTOH, my code worked (almost) out of the box, while his didn't.. :) Anyways, I don't find LOC very significant.. it's of no point these days, IMHO. Kind regards, Alex
Apr 26 2007
prev sibling parent Jan Claeys <usenet janc.be> writes:
Op Thu, 26 Apr 2007 15:39:11 +0200
schreef Don Clugston <dac nospam.com.au>:

 Wow. Would this let you implement a text-only virus (during
 compilation, secretly duplicates itself into the source code of all
 your other Nemerle projects)?
Even without knowing Nemerle I'm pretty sure you can do that, under certain conditions, but you can do that with batch files, shell scripts, Makefiles and other build scripts, etc. too. -- JanC
Apr 29 2007
prev sibling next sibling parent Dan <murpsoft hotmail.com> writes:
David B. Held Wrote:
 former President).  However, I disagree that it's *just* the library...I 
 think it is how the library is constructed.  I think the next revolution 
 in software engineering will be highly configurable and extensible 
 libraries, which will tend to obsolete the large collections of 
 redundant libraries we have today.  Because designing a highly 
 configurable library is fundamentally different from designing a 
 concrete library, I don't think there is much to be gained by simply 
Once D offers reflection I seriously think we ought to be able to implement code generators like that FPU trick someone worked on a few days ago; everyone was really excited about it, even Walter. Once someone writes such a generator using the AST, the optimal case for everyone involved is if Walter & friends integrate the concept into the D language itself (rather than a library). Why? Because a library only optimizes within that segment of code. Integrating it to D can optimize *between* segments as well; and because optimization becomes implicit <--- it always should be! For an example of what I'm thinking; an SSE2 memcpy() code generator could be developed and integrated such that if the target of the compiler has SSE2 and the buffer is predicted to be large, SSE2 is used in order to take advantage. With the AST being exposed, we can grab it and generate asm code, we can write code that can readily be integrated into D itself. Therefore, we can have lots of assembly-programmer optimal code generated for us, as well as new language features, in a sort of meta-programming way. Walter & friend's only role then is to determine the parameters which switch what code to use, and guide the proceedings.
 I think projects like Tango and TioPort are good, because these 
 foundational services are necessary for bootstrapping.  And I don't 
I think some of their stuff is useful, and other parts are not. I still don't agree with them using classes for such simple devices as arrays and strings; but the template mechanism to implement the same methods accross type seem neat and things like sockets, http, ftp and the likes are probably quite useful. On that note, I'm starting to realize that the key to making D hugely optimal is *not* to expect the library writers to write optimal asm statements for everything, but rather do it within D itself.
  [And I don't]
 think copying the STL to make the DTL was the right way to go.  D offers 
 metaprogramming facilities far and above what C++ allows.  The true 
 power of D will become apparent when DTL is resurrected with the full 
 power of D's metaprogramming system brought to bear.
 
 Anyway, that's just my 2c.
DTL doesn't matters to me; but it might to a C++ programmer considering the switch. I'm really looking forward to getting AST Reflection.
Apr 23 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
David B. Held wrote:
 
 On some level, I agree that "It's the Library, Stupid!" (to paraphrase a 
 former President).  However, I disagree that it's *just* the library...I 
 think it is how the library is constructed.  I think the next revolution 
 in software engineering will be highly configurable and extensible 
 libraries, which will tend to obsolete the large collections of 
 redundant libraries we have today. 
I very much agree.
 Because designing a highly 
 configurable library is fundamentally different from designing a 
 concrete library, I don't think there is much to be gained by simply 
 making every C++ or C or X library available in D.
Well, no. But there's a lot to be said for being able to exploit tested and established libraries "for free." And it's possible to wrap C libraries to make them easier to use, etc.
 I think projects like Tango and TioPort are good, because these 
 foundational services are necessary for bootstrapping.
For what it's worth, Tango is intended to be as modular as possible, even at the bootstrapping level. I am sure that more could be done to make the library more generic, but D templates have only recently become sufficiently robust to build a production quality library with them. I think it will take some time for new techniques to be found and for libraries to be modified to exploit new features. Personally, I am planning to wait for macros and such to be released before giving it much serious thought.
 And I don't
 think copying the STL to make the DTL was the right way to go.  D offers 
 metaprogramming facilities far and above what C++ allows.  The true 
 power of D will become apparent when DTL is resurrected with the full 
 power of D's metaprogramming system brought to bear.
Yup. I think DTL was more an early proof of concept than anything. It has the beginning of some very promising ideas, but would require a full rewrite to be truly useful for D today. Sean
Apr 23 2007
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
David B. Held wrote:

 another Java,
of high level features ever since. In version 3, there will be stuff like type inferencing, lambda expressions, etc. LINQ is really cool, too, neatly unifying in a typechecked way databases, XML, etc. There's .NET is an awesome platform. The only problem with it is that it's from Microsoft. http://www.codeproject.com/useritems/Introduction_to_C__3.asp
 Scala aims to be an academic language
That's not true. It comes from an academic environment, but it is targeted towards industry. That's why Scala is byte compatible with the JVM and Java libraries. They also support .NET, but that support has fallen behind with the latest versions. -Jeff
Apr 23 2007
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Jeff Nowakowski wrote:
 David B. Held wrote:

 another Java,
of high level features ever since. In version 3, there will be stuff like type inferencing, lambda expressions, etc. LINQ is really cool, too, neatly unifying in a typechecked way databases, XML, etc. There's .NET is an awesome platform. The only problem with it is that it's from Microsoft.
This really shows how big a role huge corporation support plays. Few languages" than what they are now. D had generics and foreach before Java, now Java has them too, maybe soon it gets true closures before D. way to go. The only way to compete with big players seems to be to do those things right where the predecessors have failed. Legacy code is what slows down things. None of the other languages seem the offer such a great combination of metaprogramming facilities and native code generation than D (maybe C++0x). Also contract programming constructs are important. Getting contract inheritance and unittests working would help a lot. It still would not please all the fp folks that prove program correctness with high level stuff like monads and pure functions, but it would help practical applications programming.
 
 http://www.codeproject.com/useritems/Introduction_to_C__3.asp
 
 Scala aims to be an academic language
That's not true. It comes from an academic environment, but it is targeted towards industry. That's why Scala is byte compatible with the JVM and Java libraries. They also support .NET, but that support has fallen behind with the latest versions. -Jeff
Apr 23 2007
parent 0ffh <spam frankhirsch.net> writes:
Hi, folks!

Just as a little by-note, let's not forget that for a large and

competition /at all/ for D, that's system programming.
Here D has only C++ and it's successor to worry about, whereof
the old variation ("classic" C++) is definitely dying, because
nobody who is in her right mind and not subjected to substantial
external pressure would want to learn (or recommend learning)
C++ over D (language stability concerns aside). IMHO, so to say.

Regards, Frank
Apr 23 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
David B. Held wrote:
 janderson wrote:
 Its about time for another round of how D can conquer the world.

 The way I see it D has 2 options, provide an easy way for C++ users to 
 switch over or become D.net.  The problem is, it is extremely 
 impracticable to switch over to D because:

 1) Everything is already in C++.  It would take months to switch over. 
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There 
 are so many API's that companies use, it is impossible to have them 
 all ported.
 3) Learning.  People are resistant to learning new things.  I think 
 this hurdle is easiest to jump if the other 2 are in place.
 [...]
another Java, Scala is actually Java + FP, and a lot of people are starting to take notice. I don't see the future as being "more Java", even though that's where the industry is heading right now. I think that people are starting to realize that software reuse is an actual possibility, despite the failed promises of the OOP revolution; but that reuse really needs full genericity to be implemented usefully (and no, I don't mean Java-style genericity).
VMs and languages running on top of VMs are probably the future for most folks. Java, CLR, and maybe some day Parrot (though I haven't heard any news about that lately). VMs can give you security, very powerful reflection, and performance acceptable for ~95% of code that gets written. And they can give a new language instance access to vast libraries of code. VMs just makes a lot of sense now that computers are generally fast enough. of CLR until Microsoft officially announces that it intends to support .NET equally across all major platforms, or open sources it. Right now their motivations with .NET are just too murky. From what I can tell Microsoft still operates with the monopolist mindset of "do whatever you can to lock 'em in". They will exploit any opportunity they can to sell more Windows licenses, because that's what their shareholders demand. Parrot is still vaporware, so that's out. So that leaves the JavaVM, which has been cross-platform from the beginning, has had a decade of work on VM optimizations under its belt, and is now open source to boot. So if you're going to build a new language on top of a VM today, seems to me like the JavaVM would be the way to go. That said, there will always be that 5% of code that really really needs the maximum performance the machine can deliver. I'd definitely rather write that in D than Fortran, C, or C++. --bb
Apr 23 2007
parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Bill Baxter wrote:
 [...]
 That said, there will always be that 5% of code that really really needs 
 the maximum performance the machine can deliver.  I'd definitely rather 
 write that in D than Fortran, C, or C++.
I think this number is much bigger than 5%. Consider that much of PC advancement has come at the hands of gamers, and gamers demand the kind of performance that will never be delivered by a VM. Whereas pr0n just drives video playback performance, games drive everything from display rendering to physics simulation to network performance, which is why games are written almost exclusively in C and C++ and comprise about a $10 billion/year industry. If you also consider that scientific and large-scale apps are almost never written on top of a VM, you are "just left" with mid- to low-end business and consumer apps. That's still a sizable chunk of the market, but by no means 95%. People have been predicting the demise of C++ almost since the beginning of Java, and yet, a decade later, it is still one of the top two languages in the world, even though Java has much better tool support and a vast army of programmers. If D captured the video game market, that would be a total coup from a PL perspective. I think that would be a pretty nifty target, but would require a huge investment in the toolchain. Dave
Apr 26 2007
next sibling parent Dan <murpsoft hotmail.com> writes:
David B. Held Wrote:

 Bill Baxter wrote:
 [...]
 That said, there will always be that 5% of code that really really needs 
 the maximum performance the machine can deliver.  I'd definitely rather 
 write that in D than Fortran, C, or C++.
I think this number is much bigger than 5%. Consider that much of PC advancement has come at the hands of gamers, and gamers demand the kind of performance that will never be delivered by a VM. Whereas pr0n just drives video playback performance, games drive everything from display rendering to physics simulation to network performance, which is why games are written almost exclusively in C and C++ and comprise about a $10 billion/year industry. If you also consider that scientific and large-scale apps are almost never written on top of a VM, you are "just left" with mid- to low-end business and consumer apps. That's still a sizable chunk of the market, but by no means 95%. People have been predicting the demise of C++ almost since the beginning of Java, and yet, a decade later, it is still one of the top two languages in the world, even though Java has much better tool support and a vast army of programmers. If D captured the video game market, that would be a total coup from a PL perspective. I think that would be a pretty nifty target, but would require a huge investment in the toolchain. Dave
I agree. Target C++ not Java. : ) AST Reflection would allow people to 'correctly' (not with strings)produce stuff like that FPU asm code generator, which we ought to develop as a community and integrate into D itself. Doing so will allow D to take advantage of 3DNow, MMX, SSE, SSE2, and x86-64 instructions based on a version switch; and generate the Agner Fog and Paul Hseih kind of optimal assembler that a good C++ game programmer has wet dreams about. At that point, D will be able to outperform C++ where it really counts, as well as being more flexible, syntactically sexier and std free. : D
Apr 26 2007
prev sibling next sibling parent reply 0ffh <spam frankhirsch.net> writes:
David B. Held wrote:
 world, even though Java has much better tool support and a vast army of 
 programmers.
Of which I suppose > 1/3 would not be able to handle the complexity of C++ even if they tried. That`s another crack where D might come in. Regards, Frank
Apr 26 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
0ffh wrote:
 David B. Held wrote:
 world, even though Java has much better tool support and a vast army 
 of programmers.
Of which I suppose > 1/3 would not be able to handle the complexity of C++ even if they tried. That`s another crack where D might come in.
C++ template metaprogramming is simply unusable for most programmers, and even for the most dedicated, it is impossible to get it to do more than fairly simple things. I aim to change that with D - metaprogramming should be as simple and natural as writing a function is.
Apr 27 2007
parent 0ffh <spam frankhirsch.net> writes:
Walter Bright wrote:
 I aim to change that with D - metaprogramming should be as simple and 
 natural as writing a function is.
Here, we say: True words, calmly spoken (well, written in this case ;-) ! Regards, Frank
Apr 27 2007
prev sibling next sibling parent janderson <askme me.com> writes:
David B. Held wrote:
 Bill Baxter wrote:
 [...]
 That said, there will always be that 5% of code that really really 
 needs the maximum performance the machine can deliver.  I'd definitely 
 rather write that in D than Fortran, C, or C++.
I think this number is much bigger than 5%. Consider that much of PC advancement has come at the hands of gamers, and gamers demand the kind of performance that will never be delivered by a VM.
be embraced by the game industry (due to XNA). Much of the gpu work and physics work will be handled by libraries (or drivers) that where written in C++ (and some C). However the core part of the game will be optimizations that matter. Of course not all games are written on windows (for instances Sony and Nintendo don't). Most developers I speak to hate the sony dev tools (I sure did). Nintendo is kinda in the same boat but its less of an issue because I think only a few games will try to push the hardware, most of the performance issues will be designed away because of the inherit limitations.
  Whereas pr0n just 
 drives video playback performance, games drive everything from display 
 rendering to physics simulation to network performance, which is why 
 games are written almost exclusively in C and C++ and comprise about a 
 $10 billion/year industry.  
I agree here however think it is becoming less of an issue with many games. However I think, the main reason C and C++ is still being used is its hard to switch to something else because of the massive potential costs (as I outlined before). XNA elevates most of these costs by providing the complete pipeline in one package.
 If you also consider that scientific and 
 large-scale apps are almost never written on top of a VM, you are "just 
 left" with mid- to low-end business and consumer apps.  That's still a 
 sizable chunk of the market, but by no means 95%.
I know a guy who has always maintained that some sciences wrote the fastest traveling salesmen problem in Java. I've argued that if you took their algorithm and put it in D or C++ it could be faster, to no avail. I can't fault him for being a die hard Java fan though, being a D fan myself. -Joel
Apr 26 2007
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
David B. Held wrote:
 Bill Baxter wrote:
 [...]
 That said, there will always be that 5% of code that really really 
 needs the maximum performance the machine can deliver.  I'd definitely 
 rather write that in D than Fortran, C, or C++.
I think this number is much bigger than 5%. Consider that much of PC advancement has come at the hands of gamers, and gamers demand the kind of performance that will never be delivered by a VM.
There's actually already movement in that direction. NCSoft is working on an MMOG that uses Java on the server side (via Sun's Project Darkstar, formerly known as the Sun Game Server) *and* on the client taking off in the indie community (with the help of GarageGames) and is most certainly going to find its way into AAA studios for games targeting both XBox and Windows. performance myth is gradually being shot down (it wasn't so long ago that the GarageGames crew regularly posted in their forums that that there's a heck of a lot of existing C++ code out there that won't be easy to replace. And that's a limiting factor for any language to gain mind share in the industry. I don't see Epic rewriting the Unreal The indie market is a different beast, though. You can find games there
 If D captured the video game market, that would be a total coup from a 
 PL perspective.  I think that would be a pretty nifty target, but would 
 require a huge investment in the toolchain.
D is already getting some indie mind share, but in addition to the weak tool chain there are other reasons why getting D into the AAA game industry is an uphill battle (as I see it): no interoperability with legacy C++ code (without a C wrapper); no full-time marketing team to go out to GDC and other conventions & gatherings to spread the word; no currently available D compilers for the console platforms... These are just off the top of my head, but they are major issues. If they could all be overcome *right now*, D would be in a perfect position to spread through the game industry like wildfire. It addresses many of the problems that developers have with C++ and offers a more attractive performance alternative (real or imagined) to those who aren't yet putting more and more of their game logic in Python and Lua, the Unreal Engine has evolved to be a dominant, end-to-end game development solution that several companies repeatedly invest in (Gamebryo and the id engines are second-class citizens in comparison). More companines are going to travel down those roads over the next few years. If D comes to the party late, it may miss the boat. To be optimistic, though, I think that the game industry is going to evolve from single-language dominance (first it was assembly, then C, now C++) to more of a multi-language melting pot as more developers with experience in different languages, and less bias, enter the industry. Multi-platform development is going to become more of the rule than the exception, so languages which make such code easier to develop and maintain will be preferred. From that perspective, D may very well ultimately find a niche within the industry. A robust game engine with a solid content pipeline will go a long way toward helping a language along. Then again, they could all be stubborn blockheads and stick with C++ forever. Project Darkstar: http://www.projectdarkstar.com/ JMonkey Engine: http://jmonkeyengine.com/ GarageGames: http://www.garagegames.com/ XNA: http://msdn2.microsoft.com/en-us/xna/default.aspx Unreal Engine: http://www.unrealtechnology.com/html/technology/ue30.shtml
Apr 27 2007
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
David B. Held wrote:
 I think this number is much bigger than 5%.  Consider that much of PC 
 advancement has come at the hands of gamers, and gamers demand the 
 kind of performance that will never be delivered by a VM.
Mike Parker wrote:

Funny you should mention Epic. A lot of their game code is not written in C++. The high performance bits like rendering are, but tons of code that makes up a game is written using a scripting language inside a virtual machine. From http://wiki.beyondunreal.com/wiki/Unreal_Engine_Core: ==== "The native software also creates a virtual machine, similar to the Java virtual machine. This is like a programming environment that sits on top of the native stuff. The language for this is UnrealScript; it's similar to Java and JavaScript. It is compiled into bytecodes, like Java, but the source remains visible, and it's this that allows the modding of the Unreal engine games. Tim Sweeney's Design goals for UnrealScript explain this idea further. "In very simple terms, every single object in the game is a piece of UnrealScript code. The engine runs all these scripts, and they decide what to do. So when the rocket hits a wall, a function in its script called something like HitAWall says: "I have hit a wall. I should now produce an explosion, make a noise, and remove myself from the game." How does the rocket know it hit a wall? The native part of the engine told it. How does the engine know? Every single moment of the game, it is checking where objects are and what they are touching." ==== Also of interest is Tim Sweeney's (architect behind Unreal) "The Next Mainstream Programming Language: A Game Developer's Perspective": http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf A good read if you want to see what a real-world, hugely successful game developer wants from a language. -Jeff
Apr 27 2007
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Jeff Nowakowski wrote:

 
 Funny you should mention Epic. A lot of their game code is not written 
 in C++.  The high performance bits like rendering are, but tons of code 
 that makes up a game is written using a scripting language inside a 
 virtual machine.
This is true of most games these days. The rendering and other system-level code is written in C++, while the game logic is handled in script (often Python, Lua, or a custom solution). UnrealScript was designed specifically for game development, with built in features like states and keywords that determine how objects are handled by the networking code. This is one of the reasons why the Unreal Engine is more than just a game engine. With the cross-platform rendering capabilities, the solid content pipeline, the built-in debugging tools -- it's a complete gaming platform. No other offering in the industry compares with it.
Apr 27 2007
parent reply Michael P <jdkfs fdksjl.com> writes:
Is there really any benefits using scripted languages besides not having to
compile? D is much faster than most scripted languages and it compiles fast and
have a garbage collector. I myself find D easier and you get better performance!
"While the C++ parts of the engine are fast, UnrealScript is a relatively slow
language to execute."
It's a sad thing when ppl underestimate the advantages of good performance.
Bump mapping could be done with an Amiga (demo but still). And if you install
Win98 on a new machine it will fly! 

Mike Parker Wrote:

 Jeff Nowakowski wrote:
 
 
 Funny you should mention Epic. A lot of their game code is not written 
 in C++.  The high performance bits like rendering are, but tons of code 
 that makes up a game is written using a scripting language inside a 
 virtual machine.
This is true of most games these days. The rendering and other system-level code is written in C++, while the game logic is handled in script (often Python, Lua, or a custom solution). UnrealScript was designed specifically for game development, with built in features like states and keywords that determine how objects are handled by the networking code. This is one of the reasons why the Unreal Engine is more than just a game engine. With the cross-platform rendering capabilities, the solid content pipeline, the built-in debugging tools -- it's a complete gaming platform. No other offering in the industry compares with it.
Apr 28 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Michael P wrote:
 Is there really any benefits using scripted languages besides not having to
compile?
 
I like to classify languages as "dynamic" or "static" languages. Dynamic languages can use features like duck typing (or otherwise dynamic typing), prototype-based object orientation, first-class functions with currying and all the other tricks, because they're not written with the processor in mind. As such, they're more suitable for interpretation than compilation, and are generally slower, but are often more expressive. Static languages are usually compiled, and have more static features: class-based object orientation, static typing, etc. By employing these static features they can be more efficient, but also lose some expressiveness. The line between these two classes becomes blurrier by the day, but D is definitely in the "static" camp. So, you could say that the advantage of scripted languages is increased dynamicism. - Gregor Richards (Yes, I know dynamicism isn't a word, but it should be, damn it!)
Apr 28 2007
next sibling parent 0ffh <spam frankhirsch.net> writes:
Gregor Richards wrote:
 So, you could say that the advantage of scripted languages is increased 
 dynamicism.
Darn! I invented that word 5 minutes ago, and now I find out you beat me to it by 2.5 hours!
 (Yes, I know dynamicism isn't a word, but it should be, damn it!)
Well, it's been invented twice at least, so I call it a word! :-) Regards, Frank
Apr 28 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Gregor Richards wrote:
 
 So, you could say that the advantage of scripted languages is increased 
 dynamicism.
 
 (Yes, I know dynamicism isn't a word, but it should be, damn it!)
"Dynamism" is, and it's pretty close to what you're looking for. Sean
Apr 28 2007
prev sibling next sibling parent janderson <askme me.com> writes:
Michael P wrote:
 Is there really any benefits using scripted languages besides not having to
compile? D is much faster than most scripted languages and it compiles fast and
have a garbage collector. I myself find D easier and you get better performance!
 "While the C++ parts of the engine are fast, UnrealScript is a relatively slow
language to execute."
 It's a sad thing when ppl underestimate the advantages of good performance.
Bump mapping could be done with an Amiga (demo but still). And if you install
Win98 on a new machine it will fly! 
 
You can't use D on a console as a scripting language, at least not as it is. Most consoles don't support anything like DLL's so things must be linked in. Something like Lua works fine as its interpreted at runtime. I think there may be a narrow gateway here for D on windows/Linux systems as a scripting language. That is a scripting language used in C/C++. The main advantage of scripting is that you can push the task over to designers (this reduces communication bottlenecks and saves the more expensive engineers time). It also provides a strong layer of abstraction that helps reduce errors. Even if you simply use the scripting language as a binding from some sort of data-driven gui. Also being able to make a change and see things change live, is a much faster turn-around time. One nice thing about a scripting language like lua is its coroutines which help keep the logic together where it should be (making it much easier to follow/write). On a negative note, I find that you can endup writing a load of binding code that would not be necessarily without scripting. Also you may write a load of functions that call a script which simply calls back a C++ function, which essentially defeats the purpose. -Joel
Apr 28 2007
prev sibling next sibling parent 0ffh <spam frankhirsch.net> writes:
Michael P wrote:
 Is there really any benefits using scripted languages besides not having to
compile? 
Yes, it's called flexibility, dynamicism, whatever. With interpreted languages you can do all things at runtime which must be done before compilation. With compiled languages all these things must be done at compile time, or before... ;-) Regards, Frank
Apr 28 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michael P wrote:
 Is there really any benefits using scripted languages besides not having to
compile? D is much faster than most scripted languages and it compiles fast and
have a garbage collector. I myself find D easier and you get better performance!
 "While the C++ parts of the engine are fast, UnrealScript is a relatively slow
language to execute."
 It's a sad thing when ppl underestimate the advantages of good performance.
Bump mapping could be done with an Amiga (demo but still). And if you install
Win98 on a new machine it will fly! 
I'm throwing my money in with Gregor on this, but I thought I'd share one of my experiences with Python. I argued for, and eventually managed to bludgeon my other project members into using Python for our third year group project at uni. I can't speak for the others, but I think that Python's dynamicism (;P) really made the thing easier to write. For instance, because we were all working on different components in the program, I designed a centralised message-passing gateway to link them all together. As the project grew, the message passing system went from msgSink.getMessage('GetSelection').send() To msgSink['GetSelection'].send() To msgSink.GetSelection() It also grew all kinds of cool stuff like the ability to directly hook a function into the messaging system like this: attach_to("GetSelection", "before-call") def BeforeGetSelection(): We implemented a whole Undo/Redo system by hooking into state change messages, and pushing the inverse operation onto a stack. We didn't need to touch a single line of code to do it; we just loaded in the "Undo" shadow objects and it worked. Even cooler was when I hacked an interactive Python shell directly into the program to use for debugging. If there was something acting up, we fired up the debugger window, and starting manually playing with the program's guts. D is a great language, certainly a huge step up from C and C++, but frankly it can't hold a candle to what Python's capable of in terms of dynamicism. Not yet, anyway. -- Daniel P.S. That's four times. We should be getting a letter from Oxford pretty soon ;) -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Apr 28 2007
parent reply Sean Kelly <sean f4.ca> writes:
Daniel Keep wrote:
 
 Michael P wrote:
 Is there really any benefits using scripted languages besides not having to
compile? D is much faster than most scripted languages and it compiles fast and
have a garbage collector. I myself find D easier and you get better performance!
 "While the C++ parts of the engine are fast, UnrealScript is a relatively slow
language to execute."
 It's a sad thing when ppl underestimate the advantages of good performance.
Bump mapping could be done with an Amiga (demo but still). And if you install
Win98 on a new machine it will fly! 
I'm throwing my money in with Gregor on this, but I thought I'd share one of my experiences with Python. I argued for, and eventually managed to bludgeon my other project members into using Python for our third year group project at uni. I can't speak for the others, but I think that Python's dynamicism (;P) really made the thing easier to write.
One issue I have with many dynamic languages is that they don't require variables to be declared before they are used. In my experience, this can turn a mistype into a bug that takes hours to find. More recently, I've noticed that the lack of type information in dynamic languages can make it very difficult to figure out how to use a piece of code. Is there an easy way to figure out what is returned from a class member function? In deep inheritance trees, figuring this out through code inspection can take a while, and it isn't always feasible to try and figure it out using interactive calls (ipython). That said, the flexibility of such languages is what makes them so powerful. I'm just not convinced I'd actually want to use them for anything but relatively compact chunks of code. Sean
Apr 28 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 One issue I have with many dynamic languages is that they don't require 
 variables to be declared before they are used.  In my experience, this 
 can turn a mistype into a bug that takes hours to find.  
Yep which is why serious Python developers swear up an down by unit tests. "If it doesn't have tests it's broken code." At least that's what I hear a lot ... however tests take time to write, and so they don't always get written. And besides wasn't I using python so I could get things done quicker? And now you tell me I have to give back all that time I saved and use it to write unit tests?! Of course they'll reply that you should be writing unit tests for your compiled code too. But it's not the same. My compiled code at least is unlikely to have any type errors. More recently,
 I've noticed that the lack of type information in dynamic languages can 
 make it very difficult to figure out how to use a piece of code.  Is 
 there an easy way to figure out what is returned from a class member 
 function?  
Yes. Write good documentation. :-) Every non-trivial python function I write gets a full-blown doc-string with INPUTS and OUTPUTS sections describing exactly what every parameter is for. Of course everyone knows it's a good idea to do this in C++ too, so Python folks will probably tell you this isn't really adding to your workload, either. In deep inheritance trees, figuring this out through code
 inspection can take a while, and it isn't always feasible to try and 
 figure it out using interactive calls (ipython).
I don't think deep inheritance trees are as necessary with duck typing. You can can do a lot more with object composition and multiple inheritance of more specific bits of functionality. Or just re-implement it. Of course some things are naturally hierarchical.
 That said, the flexibility of such languages is what makes them so 
 powerful.  I'm just not convinced I'd actually want to use them for 
 anything but relatively compact chunks of code.
Python is catching on in the scientific community, at least. Makes it easy to get the initial prototype working, similar to something like Matlab (that's usually a compact chunk of code), but gives you the option of building fancy gui web-enabled interfaces on top of that, which is difficult for most math-and-science-only tools. --bb
Apr 28 2007
prev sibling parent 0ffh <spam frankhirsch.net> writes:
Sean Kelly wrote:
 One issue I have with many dynamic languages is that they don't require 
 variables to be declared before they are used.
Yes, for me this is perhaps the single most off-putting misfeature in those languages where it is present. But OTOH I suppose it would be possible to add some variable declaration syntax (maybe hidden behind a comment) a write an utility to check for usage without declaration. Rgeards, Frank
Apr 29 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Michael P wrote:
 Is there really any benefits using scripted languages besides not having to
compile? D is much faster than most scripted languages and it compiles fast and
have a garbage collector. I myself find D easier and you get better performance!
Game content logic is typically written by non-programmers, so it's important that the language not be too complicated. Also, I suspect there is some value in using a language that isn't prone to crashing the app if something is messed up. And performance generally doesn't matter too much either (80-20 rule). Sean
Apr 28 2007
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Michael P wrote:
 Is there really any benefits using scripted languages besides not having to
compile? D is much faster than most scripted languages and it compiles fast and
have a garbage collector. I myself find D easier and you get better performance!
 "While the C++ parts of the engine are fast, UnrealScript is a relatively slow
language to execute."
Scripting languages tend to be easier for non-techies to pick up and learn, for one. By implementing the game logic in script, you make it easier for the members of the design team (who may or may not have programming experience) to implement functionality themselves and try it out immediately. Otherwise, they'd have to write out what they want, pass it off to the programmers, and wait for them to implement it and compile a new build before they can test it. The art team can use scripts to set up special effects and animations. The audio team can use scripts to set up dynamic audio effects. On a related note, the ability to implement changes to a script and see those changes reflected immediately in the game world is a tremendous time-saver. Even if you have to restart the game to see the effects it is still a far-sight better than waiting for a recompile (especially when the source tree is only recompiled on a strict schedule). New ideas can be prototyped and evaluated much more quickly. Finally, if the game is intended to be moddable by players, requiring them to learn a scripting language to do so is a far sight better than requiring them to learn C++. You can see a real world example by looking at the modding communities for the Unreal Tournament and Quake games. The latter is much smaller, but I'm certain it has to do with the fact that to mod Quake 3 you have to use C. UnrealScript is much easier to learn (and there is a lot of published material to help you do so).
 It's a sad thing when ppl underestimate the advantages of good performance.
Bump mapping could be done with an Amiga (demo but still). And if you install
Win98 on a new machine it will fly! 
No one is underestimating the advantages of performance. Game developers are among the most performance-minded software developers out there (often religiously so). But as code complexity, team sizes, and budgets have grown they have had to look for ways to increase productivity and reduce maintenance costs. Scripting allows them to do that. Performance-critical sections of the game (such as rendering) are implemented in native code, but the more of the logic you can put into scripts the better. Data-driven development in has become the rule in the game industry, rather than the exception. I look forward to seeing a feature-rich game engine developed in D (and would love to work toward that myself had I the time to do so). For such an engine to be competitive, it has to be scriptable. Whether that be with DMDScript, MiniD, Lua, Python, or (preferably) some as-yet-undeveloped-game-centric-D-based scripting language, scripting support is essential.
Apr 28 2007
parent reply Alix Pexton <_a_l_i_x_._p_e_x_t_o_n_ _g_m_a_i_l_._c_o_m_> writes:
Mike Parker wrote:
 Michael P wrote:
 Is there really any benefits using scripted languages besides not 
 having to compile? D is much faster than most scripted languages and 
 it compiles fast and have a garbage collector. I myself find D easier 
 and you get better performance!
 "While the C++ parts of the engine are fast, UnrealScript is a 
 relatively slow language to execute."
Scripting languages tend to be easier for non-techies to pick up and learn, for one. By implementing the game logic in script, you make it easier for the members of the design team (who may or may not have programming experience) to implement functionality themselves and try it out immediately. Otherwise, they'd have to write out what they want, pass it off to the programmers, and wait for them to implement it and compile a new build before they can test it. The art team can use scripts to set up special effects and animations. The audio team can use scripts to set up dynamic audio effects. On a related note, the ability to implement changes to a script and see those changes reflected immediately in the game world is a tremendous time-saver. Even if you have to restart the game to see the effects it is still a far-sight better than waiting for a recompile (especially when the source tree is only recompiled on a strict schedule). New ideas can be prototyped and evaluated much more quickly. Finally, if the game is intended to be moddable by players, requiring them to learn a scripting language to do so is a far sight better than requiring them to learn C++. You can see a real world example by looking at the modding communities for the Unreal Tournament and Quake games. The latter is much smaller, but I'm certain it has to do with the fact that to mod Quake 3 you have to use C. UnrealScript is much easier to learn (and there is a lot of published material to help you do so).
 It's a sad thing when ppl underestimate the advantages of good 
 performance. Bump mapping could be done with an Amiga (demo but 
 still). And if you install Win98 on a new machine it will fly! 
No one is underestimating the advantages of performance. Game developers are among the most performance-minded software developers out there (often religiously so). But as code complexity, team sizes, and budgets have grown they have had to look for ways to increase productivity and reduce maintenance costs. Scripting allows them to do that. Performance-critical sections of the game (such as rendering) are implemented in native code, but the more of the logic you can put into scripts the better. Data-driven development in has become the rule in the game industry, rather than the exception. I look forward to seeing a feature-rich game engine developed in D (and would love to work toward that myself had I the time to do so). For such an engine to be competitive, it has to be scriptable. Whether that be with DMDScript, MiniD, Lua, Python, or (preferably) some as-yet-undeveloped-game-centric-D-based scripting language, scripting support is essential.
With D you can have your cake and eat it! Whatever form your scripting language takes, you can have an interpreter for your designers and modders to test there scripts with, and you can then take the same scripts and include them in your final build using import()s and, if you are lucky, some of the same interpreter code to make optimized native code. The trick is getting as much of the code of the interpreter to be pure functions, so that it can shared with the DSL compiler and used in CTFE. A...
Apr 29 2007
parent reply 0ffh <spam frankhirsch.net> writes:
Alix Pexton wrote:
 Mike Parker wrote:
 With D you can have your cake and eat it!
 
 Whatever form your scripting language takes, you can have an interpreter for
 your designers and modders to test there scripts with, and you can then take
 the same scripts and include them in your final build using import()s and,
 if you are lucky, some of the same interpreter code to make optimized 
 native code.
Sorry, but no good. First of all, you make bugfixes/updates more uncomfortable and modding an impossibility. BTW, you don't need D for what you suggested. In this case it does not matter at all if you make a source-to-source transform using D's metaprogramming capabilities or in any other way. Regards, Frank
Apr 29 2007
parent reply Alix Pexton <_a_l_i_x_._p_e_x_t_o_n_ _g_m_a_i_l_._c_o_m_> writes:
0ffh wrote:
 Alix Pexton wrote:
 Mike Parker wrote:
 Sorry, but no good. First of all, you make bugfixes/updates more 
 uncomfortable
 and modding an impossibility.
I'm not at all clear what you mean by this. This can be said of any poorly thought out piece of code, which my suggestion may well be. I have no experience of programming compilers/interpreters, but I do know that both begin with lexing the source, even if that is the only common part of the 2 implementations, allowing the code to be shared between the 2 means that the language that is being processed would, on that pass at least, be the same for both. If on is able to craft a path of compatability between the 2 on further passes of the compilation, means that there is only one implementation, and I can't think if any argument that contradicts the idea that maintaining one piece of code is easier that maintaining 2 pieces of code that have to perform the same task. If, and I know it is a big if, you can write a series of pure (CTFE-able) functions that parse your script and process it as far as possible, then have 2 separate backends that take that output and at compile time fininsh processing it to native code (which we have seen done by Don with his mathematical template-foo). At runtime ou ycan then execute the same pure functions to reach the itimediate stage, and complete the processing with whatever functions you like to make the bytecode to be run in your application.
 BTW, you don't need D for what you suggested.
I'd be interested in looking at any other language that that compiles to native code, and can used the same functions at compile time and run time to process a DSL. I've not come accross any others yet.
 In this case it does not matter at all if you make a source-to-source 
 transform
 using D's metaprogramming capabilities or in any other way.
I admit that I did not make this point at all well in my previous post. I wasn't trying to suggest DSL-to-D translation, if that is what you mean by "source-to-source", only that in D you have the option to use the same code at run-time and compile-time, so, if in implementing an engine that needs to be able to load logic dynamically during development, you can with careful implementaion, use the same code to import and compile those same scripts into the executeable when making a release build. A...
Apr 30 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Alix Pexton wrote:

 I admit that I did not make this point at all well in my previous post. 
 I wasn't trying to suggest DSL-to-D translation, if that is what you 
 mean by "source-to-source", only that in D you have the option to use 
 the same code at run-time and compile-time, so, if in implementing an 
 engine that needs to be able to load logic dynamically during 
 development, you can with careful implementaion, use the same code to 
 import and compile those same scripts into the executeable when making a 
 release build.
 
Then that defeats the purpose, doesn't it? The idea of scripting is to avoid recompiling the host application. This is especially important to allow modding by users. The goal is for your target scripters, be it the development team or the players, to be able fire up a text editor, make changes to the script, and see them immediately in the game. Requiring CTFE of scripts doesn't make sense in that case.
Apr 30 2007
parent reply Alix Pexton <_a_l_i_x_._p_e_x_t_o_n_ _g_m_a_i_l_._c_o_m_> writes:
Mike Parker wrote:
 Alix Pexton wrote:
 
 I admit that I did not make this point at all well in my previous 
 post. I wasn't trying to suggest DSL-to-D translation, if that is what 
 you mean by "source-to-source", only that in D you have the option to 
 use the same code at run-time and compile-time, so, if in implementing 
 an engine that needs to be able to load logic dynamically during 
 development, you can with careful implementaion, use the same code to 
 import and compile those same scripts into the executeable when making 
 a release build.
Then that defeats the purpose, doesn't it? The idea of scripting is to avoid recompiling the host application. This is especially important to allow modding by users. The goal is for your target scripters, be it the development team or the players, to be able fire up a text editor, make changes to the script, and see them immediately in the game. Requiring CTFE of scripts doesn't make sense in that case.
Thats not what I said. I'm obviously not getting my self accross. While your scripts are at the design stage, you can load them dynamically and run them as interpretted code, so you don't have to compile them. When you release your product, you can have those scripts precompiled as part of the build process. The interpretter is still a part of the program, and the modders can run there scripts on it just like the developers did, and if they have access to a D compiler, and the meta-compiler code (which the developer will of course be free to distribute as with any tool they create,) then they can compile the script themselves to make a lib (or whatever) that can then be run natively. The point that I am trying to get over is not that D can pre compile a DSL and that is better than interpretting it, but that if the code is written with a few constraints in mind, then you can have the advantages of both systems, and only have to maintain one code base. A...
Apr 30 2007
parent Alix Pexton <_a_l_i_x_._p_e_x_t_o_n_ _g_m_a_i_l_._c_o_m_> writes:
 (which the developer will of course be free to distribute as with any 
 tool they
 create,) then they can compile the script themselves to make a lib (or 
 whatever) that
 can then be run natively.
oops, not a lib, rather a DLL or .so, I believe mods for HalfLife where compiled to DLLs. A...
Apr 30 2007
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Jeff Nowakowski wrote:
 David B. Held wrote:
 
 I think this number is much bigger than 5%.  Consider that much of PC 
 advancement has come at the hands of gamers, and gamers demand the 
 kind of performance that will never be delivered by a VM.
Mike Parker wrote:

Funny you should mention Epic. A lot of their game code is not written in C++. The high performance bits like rendering are, but tons of code that makes up a game is written using a scripting language inside a virtual machine. From http://wiki.beyondunreal.com/wiki/Unreal_Engine_Core: ==== "The native software also creates a virtual machine, similar to the Java virtual machine. This is like a programming environment that sits on top of the native stuff. The language for this is UnrealScript; it's similar to Java and JavaScript. It is compiled into bytecodes, like Java, but the source remains visible, and it's this that allows the modding of the Unreal engine games. Tim Sweeney's Design goals for UnrealScript explain this idea further. "In very simple terms, every single object in the game is a piece of UnrealScript code. The engine runs all these scripts, and they decide what to do. So when the rocket hits a wall, a function in its script called something like HitAWall says: "I have hit a wall. I should now produce an explosion, make a noise, and remove myself from the game." How does the rocket know it hit a wall? The native part of the engine told it. How does the engine know? Every single moment of the game, it is checking where objects are and what they are touching."
As far as I understand it, D would be the language for creating stuff like the Unreal Engine. This would be Systems Programming, i.e. what D purports to excel at. Of course, the VHLGL (very high level game logic) could (probably should and would) be written in some high-level (probably) interpreted language. STILL, such logic (as compared to Java, Python, ECMA-script, Lua, etc) probably would be almost as easy to write in D. And, thinking of large game industries, once they've decided on using D, they'd probably write some source code translators that would translate their existing in-house high-level game logic scripts to D.
 Also of interest is Tim Sweeney's (architect behind Unreal) "The Next 
 Mainstream Programming Language: A Game Developer's Perspective":
 
 http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
 
 A good read if you want to see what a real-world, hugely successful game 
 developer wants from a language.
 
 -Jeff
Apr 29 2007
parent janderson <askme me.com> writes:
Georg Wrede wrote:
 Jeff Nowakowski wrote:
 David B. Held wrote:
 
 As far as I understand it, D would be the language for creating stuff 
 like the Unreal Engine. This would be Systems Programming, i.e. what D 
 purports to excel at.
 
 Of course, the VHLGL (very high level game logic) could (probably should 
 and would) be written in some high-level (probably) interpreted 
 language. STILL, such logic (as compared to Java, Python, ECMA-script, 
 Lua, etc) probably would be almost as easy to write in D.
 
 And, thinking of large game industries, once they've decided on using D, 
 they'd probably write some source code translators that would translate 
 their existing in-house high-level game logic scripts to D.
 
That would be true for a number of studios however generally I find scripts are treated as throwaway code. Thats why they they are a perfect entry point for D (no legacy code to worry about) . I also think D would make a much better scripting language then say Lua for design. You could always write a DSL if necessary. -Joel
Apr 29 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
David B. Held wrote:
 If D captured the video game market, that would be a total coup from a 
 PL perspective.  I think that would be a pretty nifty target, but would 
 require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
Apr 27 2007
next sibling parent reply janderson <askme me.com> writes:
Walter Bright wrote:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from a 
 PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
That will be awesome. Just my 2p You probably want to figure out good/diplomatic answers for these questions. - How to reuse legacy C++ code? - Linking to legacy C++ code? - What other games have been created in D? - Working on consoles in D? (Most consoles work with gdc, so I think its possible). You may also want to talk about where else D can be used if not for the main engine. The rest of D will sell itself ;) Good luck.
Apr 28 2007
parent reply Georg Wrede <georg nospam.org> writes:
janderson wrote:
 Walter Bright wrote:
 
 David B. Held wrote:

 If D captured the video game market, that would be a total coup from 
 a PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
That will be awesome. Just my 2p You probably want to figure out good/diplomatic answers for these questions. - How to reuse legacy C++ code? - Linking to legacy C++ code? - What other games have been created in D?
Right now browsing through Doom source code, I wonder if it would be a good idea to translate that to D. And even better, if it looks successful, then write about it on DDJ or some other magazine.
 - Working on consoles in D? (Most consoles work with gdc, so I think its 
 possible).
 
 You may also want to talk about where else D can be used if not for the 
 main engine.
 
 The rest of D will sell itself ;)
 
 Good luck.
Apr 29 2007
next sibling parent janderson <askme me.com> writes:
Georg Wrede wrote:
 janderson wrote:
 Walter Bright wrote:

 David B. Held wrote:

 If D captured the video game market, that would be a total coup from 
 a PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
That will be awesome. Just my 2p You probably want to figure out good/diplomatic answers for these questions. - How to reuse legacy C++ code? - Linking to legacy C++ code? - What other games have been created in D?
Right now browsing through Doom source code, I wonder if it would be a good idea to translate that to D. And even better, if it looks successful, then write about it on DDJ or some other magazine.
 - Working on consoles in D? (Most consoles work with gdc, so I think 
 its possible).

 You may also want to talk about where else D can be used if not for 
 the main engine.

 The rest of D will sell itself ;)

 Good luck.
Sounds like a good idea. Doom has been ported to everything else, so why not D :) -Joel
Apr 29 2007
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Georg Wrede wrote:

 
 Right now browsing through Doom source code, I wonder if it would be a 
 good idea to translate that to D. And even better, if it looks 
 successful, then write about it on DDJ or some other magazine.
Quake 3 would be more interesting to port, I think, given that it's more recent. I started to do just that a while back, but just didn't have the time to keep with it. It's always in the back of my mind, though.
Apr 29 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Mike Parker wrote:
 Georg Wrede wrote:
 
 Right now browsing through Doom source code, I wonder if it would be a 
 good idea to translate that to D. And even better, if it looks 
 successful, then write about it on DDJ or some other magazine.
Quake 3 would be more interesting to port, I think, given that it's more recent. I started to do just that a while back, but just didn't have the time to keep with it. It's always in the back of my mind, though.
Geez I need to get with the times. Quake 3 source has been released? ---bb
Apr 29 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Bill Baxter wrote:
 Mike Parker wrote:
 Georg Wrede wrote:

 Right now browsing through Doom source code, I wonder if it would be 
 a good idea to translate that to D. And even better, if it looks 
 successful, then write about it on DDJ or some other magazine.
Quake 3 would be more interesting to port, I think, given that it's more recent. I started to do just that a while back, but just didn't have the time to keep with it. It's always in the back of my mind, though.
Geez I need to get with the times. Quake 3 source has been released?
About a year-and-a-half ago. You can find the id release at: http://www.fileshack.com/file.x?fid=7547. But I'd recommend ioquake 3: http://ioquake3.org/ This code base includes several bug fixes to the original id release, is ported to more platforms, plays nicely with gcc on Windows, has an SDL system implementation, uses OpenAL for sound, has support for ogg vorbis, and a good deal more. When I started the D port I was working with the id release, but if I ever go back to it I'll use ioq3.
Apr 29 2007
parent Clay Smith <clayasaurus gmail.com> writes:
Mike Parker wrote:
 Bill Baxter wrote:
 Mike Parker wrote:
 Georg Wrede wrote:

 Right now browsing through Doom source code, I wonder if it would be 
 a good idea to translate that to D. And even better, if it looks 
 successful, then write about it on DDJ or some other magazine.
Quake 3 would be more interesting to port, I think, given that it's more recent. I started to do just that a while back, but just didn't have the time to keep with it. It's always in the back of my mind, though.
Geez I need to get with the times. Quake 3 source has been released?
About a year-and-a-half ago. You can find the id release at: http://www.fileshack.com/file.x?fid=7547. But I'd recommend ioquake 3: http://ioquake3.org/ This code base includes several bug fixes to the original id release, is ported to more platforms, plays nicely with gcc on Windows, has an SDL system implementation, uses OpenAL for sound, has support for ogg vorbis, and a good deal more. When I started the D port I was working with the id release, but if I ever go back to it I'll use ioq3.
The best way to do this is probably a mix of automatic C/C++ code translation for the easy things (like types), and hand code translation to fill in the gaps. Also, the project would probably be helped if it were easily accessible to many people at once, where anyone could figure out what needed to be done for the project (by looking through the list of files kept of translated vs. non-translated sources, or making a ticket for every single file needed to be translated on dsource). 90% of the project could probably be handled by auto conversion + community conversion, the last 10% will be having an expert critically analyze the code, fix bugs, and getting the project to run. ~ Clay
Apr 30 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Georg Wrede wrote:
 janderson wrote:
 Walter Bright wrote:

 David B. Held wrote:

 If D captured the video game market, that would be a total coup from 
 a PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
That will be awesome. Just my 2p You probably want to figure out good/diplomatic answers for these questions. - How to reuse legacy C++ code? - Linking to legacy C++ code? - What other games have been created in D?
Right now browsing through Doom source code, I wonder if it would be a good idea to translate that to D. And even better, if it looks successful, then write about it on DDJ or some other magazine.
You mean the original Doom? I don't think that's going to impress anyone. Quake for cell phones or Quake 2 for the PC might be interesting. --bb
Apr 29 2007
prev sibling parent janderson <askme me.com> writes:
  > Right now browsing through Doom source code, I wonder if it would be a
 good idea to translate that to D. And even better, if it looks 
 successful, then write about it on DDJ or some other magazine.
 
I guess if any popular game was ported, it would be nice to show how much easier D would have made it to program. -Joel
Apr 29 2007
prev sibling next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from a 
 PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
This is an extremely good opportunity, bring your best Walter!
Apr 28 2007
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Walter Bright wrote:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from a 
 PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
You had me confused for a minute, since *the* GDC was March 5~9. So then I thought you were talking about the AGDC (Austin Game Developer's Conference), but that's in September. A quick Google led me to the site of the very new OGDC (Online Game Developers Conference) being held in Seattle on May 10~11. And on there on the list of speakers is Walter Bright. Cool beans :) http://www.ogdc2007.com/
Apr 29 2007
prev sibling next sibling parent reply david <ta-nospam-zz gmx.at> writes:
Walter Bright schrieb:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from a 
 PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
Since no one dropped the link so far, I'll do it... Deadlock, see http://www.team0xf.com/eng/ david
Apr 30 2007
next sibling parent reply janderson <askme me.com> writes:
david wrote:
 Walter Bright schrieb:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from 
 a PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
Since no one dropped the link so far, I'll do it... Deadlock, see http://www.team0xf.com/eng/ david
Looks like a pretty awesome proof-of-concept for D. PS - Wasn't there already a game called Deadlock?
Apr 30 2007
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
First of all, thanks for all the feedback, guys :) It matters a lot to us.



 Here's another thought.  Emphasizers how much faster D can compile 
then C++ due to the language features. I don't know of a game company (I keep in contact with only about 6 or 7) that isn't using something like incredbuild (or discc) and still battling with compile-times. Deadlock has about 67,000 lines of our own code, plus lots of dependencies which we don't even bother compiling into static libs. Along with these dependencies, it compiles within about 30 seconds on Pentium D 3.2 and Centrino 1.7. There are also some more external dependencies that sit in DLLs which are mostly C++ code. They take about another 30 seconds, but are compiled rarely. D's quick compile times along with DDL allow us to use quite an interesting rendering architecture, which resembles a microkernel design. In future, these 'kernels' or 'shaders' will be dynamically recompiled and reloaded at runtime.
 PS - Wasn't there already a game called Deadlock?
Yup, a strategy game. Deadlock is just a codename, so I guess they won't be after us ;) Some info on the project: Deadlock is currently being developed by five univ students for the 'Team Programming' course at Nicolaus Copernicus University in Torun, Poland. The development has lasted about 6 months, during which we've coded lots of cool features, such as: - OpenGL-based rendering with Cg boosted graphics and fallbacks for older machines - Particle systems - Skeletal animation - 3d sound - Networked physics using the PhysX middleware - Framebuffer effects - Pretty advanced (IMHO) scene graph management - Custom Immediate Mode GUI - In-game console - Custom model exporter (MAXScript) and importer (D) - Quake3 BSP level loading and rendering It wouldn't be quite possible in any other language... Some of us had prior C++ knowledge, some knew Java, others a bit of Python. None of the languages would do quite the job that D did. As the lead programmer, I talked the rest of the team into trying out D and they got sucked in. Most of us had little to no idea about game or 3d graphics programming prior to the project, and yet it turns out that it's possible to learn D, 3d and game programming AND make a cool game in half a year. I hope no one minds the shameless self-promoting. We wanted to publish some info about the project after its official presentation on May, 10th but as the info has already 'leaked' to the NG ;) then maybe someone might want to hear more about it. We're currently in the process of adding last features into the game, polishing it as far as possible and preparing for the presentation. I'm definitely looking forward to continuing the project later and I hope the team will share the same passion :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
May 02 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tom S wrote:
 First of all, thanks for all the feedback, guys :) It matters a lot to us.
I want to put together a slide on your project for my talk at the upcoming game developers' conference.
 Some info on the project:
 Deadlock is currently being developed by five univ students for the 
 'Team Programming' course at Nicolaus Copernicus University in Torun, 
 Poland. The development has lasted about 6 months, during which we've 
 coded lots of cool features, such as:
 - OpenGL-based rendering with Cg boosted graphics and fallbacks for 
 older machines
 - Particle systems
 - Skeletal animation
 - 3d sound
 - Networked physics using the PhysX middleware
 - Framebuffer effects
 - Pretty advanced (IMHO) scene graph management
 - Custom Immediate Mode GUI
 - In-game console
 - Custom model exporter (MAXScript) and importer (D)
 - Quake3 BSP level loading and rendering
 
 It wouldn't be quite possible in any other language...
Why? (I want to know, because I'll get asked this!)
 Some of us had 
 prior C++ knowledge, some knew Java, others a bit of Python. None of the 
 languages would do quite the job that D did. As the lead programmer, I 
 talked the rest of the team into trying out D and they got sucked in. 
 Most of us had little to no idea about game or 3d graphics programming 
 prior to the project, and yet it turns out that it's possible to learn 
 D, 3d and game programming AND make a cool game in half a year.
This is good stuff, mind if I quote you for my presentation?
 I hope no one minds the shameless self-promoting. We wanted to publish 
 some info about the project after its official presentation on May, 10th 
 but as the info has already 'leaked' to the NG ;) then maybe someone 
 might want to hear more about it.
My talk will be on the 11th.
 
 We're currently in the process of adding last features into the game, 
 polishing it as far as possible and preparing for the presentation. I'm 
 definitely looking forward to continuing the project later and I hope 
 the team will share the same passion :)
 
 
May 02 2007
next sibling parent reply kenny <funisher gmail.com> writes:
Walter Bright wrote:
 I want to put together a slide on your project for my talk at the
 upcoming game developers' conference.
You're speaking at the GDC?! AWESOME!!! Not the official one? I think that was like a month ago or something...
May 02 2007
parent Mike Parker <aldacron71 yahoo.com> writes:
kenny wrote:
 Walter Bright wrote:
 I want to put together a slide on your project for my talk at the
 upcoming game developers' conference.
You're speaking at the GDC?! AWESOME!!! Not the official one? I think that was like a month ago or something...
Heh, it's the OGDC (Online Game Developer's Conference). Walter: Unless you specify the 'O', people automatically think "GDC" when they see "game developer's conference". It's confusing!
May 02 2007
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 Tom S wrote:
 First of all, thanks for all the feedback, guys :) It matters a lot to 
 us.
I want to put together a slide on your project for my talk at the upcoming game developers' conference.
That'd be awesome :D And if you do, we won't hesitate to mention it on our presentation either :>
 It wouldn't be quite possible in any other language...
Why? (I want to know, because I'll get asked this!)
I've written my share of C++, Java and Python code (as well as tried other languages) and only D gives the right runtimePerformance/codingEase ratio. When I write code in D (and I hear it happens with other team members as well), it simply... compiles and runs. Debugging is also trivial, especially when using the backtrace hack. DBC and lots of non-release checks do the job really well. If the code crashes, it crashes early and it's instantly visible where. The only non-trivial problems are memory corruptions that can happen when playing too much with pointers or deleting objects carelessly and escaping local delegate contexts. With a bit of experience, these can be found quickly as well, though. On the other hand, if we coded in C++, we'd spend ages on constant re-compilation, then deep within a debugger battle bugs which are normally trivially caught by D's DBC. Templates would be terrible to write, instead of the breeze that D yields. We'd have to use lots of Boost, read 200-line error messages, and write at least 40% more code just because the language needs us to. And for the 100th time when someone on the team used a delete instead of delete[], I'd slash my wrists. Just as with 'if (a = value)' or 'for ( ... ); {}'. Not to mention that some stuff would be quite impossible, such as my custom preprocessor for the rendering kernels/shaders. Had we coded in Java, we'd have to be more careful about memory allocations than in D or C++, use lots of hacks to make the resulting code fast. Before the end of the project, we'd all have RSI because of typing 'new' too many times. In the end, it would turn out that the presentation PCs have JRE 1.5.0.1.3.5.3 instead of 1.5.0.1.3.5.4 which our project was designed for and we'd have another reason not to believe that Java is portable (as 2/3 of teams at the univ realize each year on the team programming course). As far as other languages are concerned, that'd be mix of the C++ and Java horror scenarios, plus-minus performance implications that'd cause the game to be too sluggish to be fun. The only language better than D for game programming would be D coupled with a dynamic lang, such as Io, Squirrel, Lua or Python.
 This is good stuff, mind if I quote you for my presentation?
Not at all :) *thinks* Woah I will be famous ;D *thinks*
 My talk will be on the 11th.
Aye! We'll share a video recording, will you ? :D -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
May 02 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Thanks for yours and Peter's replies. This is good stuff.

Can you two combine your comments and put together a web page of the 
results, and add it to your web site? I think this could be very good; 
we can try to get it on digg, dzone, gamedev.net, etc.!
May 03 2007
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 Thanks for yours and Peter's replies. This is good stuff.
 
 Can you two combine your comments and put together a web page of the 
 results, and add it to your web site? I think this could be very good; 
 we can try to get it on digg, dzone, gamedev.net, etc.!
Yea, sure :] But I hope it's not needed before the presentation, as we're knee-deep within the preparations... Let's say that we'll put up a more thorough webpage and an openly downloadable version of Deadlock after 10th, but if you need some specifics/screenshots/videos/exe to mention on your OGDC presentation, let us know and we'll email you some stuff :] -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
May 03 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Tom S wrote:
 Walter Bright wrote:
 Thanks for yours and Peter's replies. This is good stuff.

 Can you two combine your comments and put together a web page of the 
 results, and add it to your web site? I think this could be very good; 
 we can try to get it on digg, dzone, gamedev.net, etc.!
Yea, sure :] But I hope it's not needed before the presentation, as we're knee-deep within the preparations... Let's say that we'll put up a more thorough webpage and an openly downloadable version of Deadlock after 10th, but if you need some specifics/screenshots/videos/exe to mention on your OGDC presentation, let us know and we'll email you some stuff :]
For the presentation, I won't be able to do more than one slide for this, which is maybe 4-8 lines. I'm looking to the future, though, with your game being a case study in using D for game programming. Having a major, professional game in D with a nice writeup on how it was done can open a lot of eyes for us and raise D's profile. It's a big plus, too, that you're using a number of D libraries written by the D community. But I can still use a nice jpg screenshot for the presentation! Your best one!
May 03 2007
prev sibling next sibling parent Peter Modzelewski <peter.modzelewski gmail.com> writes:
Walter Bright napisał(a):
 Tom S wrote:
 First of all, thanks for all the feedback, guys :) It matters a lot to 
 us.
I want to put together a slide on your project for my talk at the upcoming game developers' conference.
Hi I'm KeYeR from team0xf. I'm responsible for skeletal animation, sound system, bsp levels. Also I'm helping a little with gameplay and renderer. I think that it will be a great honor for us if you mention our project on such a conference :)
 Some info on the project:
 Deadlock is currently being developed by five univ students for the 
 'Team Programming' course at Nicolaus Copernicus University in Torun, 
 Poland. The development has lasted about 6 months, during which we've 
 coded lots of cool features, such as:
 - OpenGL-based rendering with Cg boosted graphics and fallbacks for 
 older machines
 - Particle systems
 - Skeletal animation
 - 3d sound
 - Networked physics using the PhysX middleware
 - Framebuffer effects
 - Pretty advanced (IMHO) scene graph management
 - Custom Immediate Mode GUI
 - In-game console
 - Custom model exporter (MAXScript) and importer (D)
 - Quake3 BSP level loading and rendering

 It wouldn't be quite possible in any other language...
Why? (I want to know, because I'll get asked this!)
- quick compilation - easy debugging without special tools: asserts, exceptions, unittests and writelfn debug info are enough in 99,99% of cases, thx to D it's harder to do stupid mistakes - templates, delegates and other builtin D features let us use auto-magical solutions - D lets us build high level interfaces but also allows us to go low when optimizaitons are necessery. - D is just neat... code can look good and work fast - we were able to use c/c++ libraries via bindings without any problems. Personally I'm not much longer a D programmer then deadlock is going. I've learned it quickly and right on I was able to use it in serious projects (not only in deadlock). I know java quite well and was coding in c++ also. I'm sure that it would be impossible to write as much and as quick in the mentioned languages. Many times when writing the skeletal animation library, where i used lots of delegates, templates (our skeletal animation library is one big template really :P), hash tables, dynamic tables etc a lot of times i was delighted with things I am able to do in D. In D I code what I have in mind, in C++ I would have to think how to hack things to get what I want .
 
 Some of us had prior C++ knowledge, some knew Java, others a bit of 
 Python. None of the languages would do quite the job that D did. As 
 the lead programmer, I talked the rest of the team into trying out D 
 and they got sucked in. Most of us had little to no idea about game or 
 3d graphics programming prior to the project, and yet it turns out 
 that it's possible to learn D, 3d and game programming AND make a cool 
 game in half a year.
This is good stuff, mind if I quote you for my presentation?
 I hope no one minds the shameless self-promoting. We wanted to publish 
 some info about the project after its official presentation on May, 
 10th but as the info has already 'leaked' to the NG ;) then maybe 
 someone might want to hear more about it.
My talk will be on the 11th.
good luck! :) I really am addicted to D. One of the things I'm mostly afraid of is that I would be made to code in C++ or Java in my future work. Conferences like that bring me shadow of hope that there would be place for D coders in the game industry when I finish my studies. As this is my first post directed to you, I personally want to thank you for creating such a great language. I am sure D will change the coders' world for good. KeYeR
May 02 2007
prev sibling parent Serg Kovrov <kovrov no.spam> writes:
Walter Bright wrote:
 I want to put together a slide on your project for my talk at the 
 upcoming game developers' conference.
Will video of you talk be available? -- serg.
May 10 2007
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Tom S wrote:
 First of all, thanks for all the feedback, guys :) It matters a lot to us.
 
Here have some more. :) I remember seeing this earlier and thinking "sweet! a really big game project coded in D!" I'm glad you posted more info here, and also glad it is working out so well. I guess it's too late for me to sign up for a beta since you are going to present it like next week or something, but I will eagerly await the release. Also, it would be really cool if you decide to release the source code some day. I'd love to see what 3d game engine code looks like in D. Good luck with your presentation!
May 02 2007
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Chad J wrote:
 I remember seeing this earlier and thinking "sweet! a really big game 
 project coded in D!"  I'm glad you posted more info here, and also glad 
 it is working out so well.  I guess it's too late for me to sign up for 
 a beta since you are going to present it like next week or something, 
 but I will eagerly await the release.
There will surely be an announcement on the NG :)
 Also, it would be really cool if you decide to release the source code 
 some day.  I'd love to see what 3d game engine code looks like in D.
Up to about 100 revisions ago, it used to be public: http://deadlockd.googlecode.com/svn/trunk/ We've exceeded the quota on Google, they haven't answered so we moved it out of Google. I'm not sure if the team would want to release the current version of the code to the wide public, but I guess we could organize some SVN access to D programmers interested in trying out the engine, helping us in some way or whatnot ;) As for the seeing how 3d game engine code looks in D... well, that's a pretty novel design, none of us has ever read any other engine code so you might be a bit surprised/shocked about Deadlock's ;)
 Good luck with your presentation!
Thanks! :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
May 02 2007
prev sibling parent reply david <ta-nospam-zz gmx.at> writes:
Tom S schrieb:
 
 We wanted to publish 
 some info about the project after its official presentation on May, 10th 
 but as the info has already 'leaked' to the NG ;) then maybe someone 
 might want to hear more about it.
 
Sorry for that, but seeing that Walter would have his talk at OGDC May 11th, I though it would be a great opportunity :-) david
May 03 2007
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
david wrote:
 Tom S schrieb:
 We wanted to publish some info about the project after its official 
 presentation on May, 10th but as the info has already 'leaked' to the 
 NG ;) then maybe someone might want to hear more about it.
Sorry for that, but seeing that Walter would have his talk at OGDC May 11th, I though it would be a great opportunity :-)
Yea, you did the right thing ;) *pats* -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
May 03 2007
prev sibling next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
david wrote:
 Walter Bright schrieb:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from 
 a PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
Since no one dropped the link so far, I'll do it... Deadlock, see http://www.team0xf.com/eng/
Sweet! Awesome technology demo for D! There should definitely be a link on the D site... Dave
Apr 30 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
David B. Held wrote:
 Since no one dropped the link so far, I'll do it...
 Deadlock, see http://www.team0xf.com/eng/
Sweet! Awesome technology demo for D! There should definitely be a link on the D site...
Actually, if people could post/email to me a list of links of games in D, I can make up a slide for it. Nothing works like examples!
May 01 2007
next sibling parent jcc7 <technocrat7 gmail.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 David B. Held wrote:
 Since no one dropped the link so far, I'll do it...
 Deadlock, see http://www.team0xf.com/eng/
Sweet! Awesome technology demo for D! There should definitely be a link on the D site...
Actually, if people could post/email to me a list of links of games in D, I can make up a slide for it. Nothing works like examples!
We've got a wiki page to list games written in D, but I don't know if they're good examples (some of them might not be in active development anymore -- or it's even possible there's a vaporware project in there): http://www.prowiki.org/wiki4d/wiki.cgi?Games jcc7
May 01 2007
prev sibling parent Clay Smith <clayasaurus gmail.com> writes:
Walter Bright wrote:
 David B. Held wrote:
 Since no one dropped the link so far, I'll do it...
 Deadlock, see http://www.team0xf.com/eng/
Sweet! Awesome technology demo for D! There should definitely be a link on the D site...
Actually, if people could post/email to me a list of links of games in D, I can make up a slide for it. Nothing works like examples!
There is also FreeUniverse http://www.dsource.org/projects/freeuniverse/wiki/WikiStart http://svn.dsource.org/projects/freeuniverse/downloads/freeuniverse.zip The download contains a windows exe, but the game could also be compiled for linux as well. ~ Clay
May 02 2007
prev sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
David B. Held wrote:
 david wrote:
 Walter Bright schrieb:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from 
 a PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
Since no one dropped the link so far, I'll do it... Deadlock, see http://www.team0xf.com/eng/
Sweet! Awesome technology demo for D! There should definitely be a link on the D site... Dave
Having played an early Beta of this myself, I can say without reservation that this is one of the coolest D projects going. Its also the largest "superproject" for D. -- - EricAnderton at yahoo
May 01 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
david wrote:
 Since no one dropped the link so far, I'll do it...
 Deadlock, see http://www.team0xf.com/eng/
It's a way cool website design, too!
May 01 2007
prev sibling parent janderson <askme me.com> writes:
Walter Bright wrote:
 David B. Held wrote:
 If D captured the video game market, that would be a total coup from a 
 PL perspective.  I think that would be a pretty nifty target, but 
 would require a huge investment in the toolchain.
I'll be giving a talk on D at the upcoming game developers conference May 11.
Here's another thought. Emphasizers how much faster D can compile then C++ due to the language features. I don't know of a game company (I keep in contact with only about 6 or 7) that isn't using something like incredbuild (or discc) and still battling with compile-times. -Joel
May 01 2007
prev sibling next sibling parent eao197 <eao197 intervale.ru> writes:
On Mon, 23 Apr 2007 07:05:02 +0400, janderson <askme me.com> wrote:

 The way I see it D has 2 options, provide an easy way for C++ users to  
 switch over or become D.net.  The problem is, it is extremely  
 impracticable to switch over to D because:

 1) Everything is already in C++.  It would take months to switch over.  
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There are  
 so many API's that companies use, it is impossible to have them all  
 ported.
You talk about 'switching form C++ to D' to port and maintain existing C++ code base to D. But there is another part of story: new software must be written and it can be written without need of porting big amount of C++ code to D. Why not to continue support of C++ projects in C++ and start new projects in D?
 3) Learning.  People are resistant to learning new things.  I think this  
 hurdle is easiest to jump if the other 2 are in place.
D is a easy way to jump form C++ to something modern and powerful. I spent big amount of time last two years searching a competitive alternative to C++ (I learnt Eiffel, Nemerle, Scala, D and looked on some other languages). And D is the most similar to C++ than any other and I (as a long-time C++ user) found that D is the most comfortable language for me. So I can say that learning D after C++ is much much easier task then learning, for example, Scala.
 D.Net option:
and VB.NET with VisualStudio and other IDEs. In the future .Net would get yet another very promised language -- Nemerle. So may be better alternative is to make a D-to-JVM byte code compiler :) And my 2 copecks about 'how D can conquer the world' :) I don't care about couquering the world. It doesn't matter for me would be me, my team and my tasks. I know D is useful for me. And I have started to port some of our home-grown frameworks to D. I know D is more simple than ó++ and, in some cases, more powerful. I know that because I have learnt it. So I can teach my team to program in D and I know this would be much easier then teaching C++. I know D has almost all that I need for my current tasks (thanks to Tango team) and I can write missing ones. But at the current moment of time usage of D seems too risky because of: * language itself constantly changes. I don't think it is a big problem in my case because I hope that D will be stabilized in near future and that time will be spent by doing some proof-of-concept, non-business-critical projects; * lack of tools and libraries. I don't need sophisticated IDE for myself (VIM is an ultimate answer;) ), but many people think that language has no future if it doesn't have Idea- or VisualStudio-like IDE; * lack of promotion. It should be much more information about D in the world: books (something like 'The C++ Programming Language' and 'Programming Ruby 2nd'), tuturials, articles, blogs and discussions in various forums. Not only in English, but in different languages in different countries. I can say that in Russia (Belarus, Ukraine) there are much programmers who don't know English enough to learn new language, but about these languages in Russian (translated and originaly written books, articles, big programmers forums and so on); * lack of success stories. I think it is very important when it is possible to demonstrate some examples of successful usage of D to chiefs. I told about D and perspectives of its usage to my chief a short time ago and got simple question: "It is interesting, but who use D now and what have been written in D?". But I hope those are temporary problems and they will gone away as D and D community will grow. -- Regards, Yauheni Akhotnikau
Apr 23 2007
prev sibling next sibling parent Dan <murpsoft hotmail.com> writes:
janderson Wrote:

 Xinok wrote:
 D only needs two things, though two very big things:
 
 1) A proper IDE
 2) Many more libraries
 
 The language itself, D, offers enough to make it a practical choice over 
 C++.

 more, and because of Microsoft's resources, it has a proper IDE and tons 


or Java. It appears to me, that many of the 3rd party libraries I use on a day to day basis would never become part of these many-libraries. People simply don't want to re-invent the wheel. -Joel
Excuse the weirdness, I haven't slept all weekend: ~~ Wheels invented in C++ are not really wheels at all! Nobody can use them but C++ programmers, and even then it often depends on the compiler. Let us go forth, and find a means of binding C++ obj files such that they may be imported within C and D; that we may inherit their legacy code! Is it possible to create a D friendly obj file with the dmc?
Apr 23 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
janderson Wrote:

 Its about time for another round of how D can conquer the world.
 
 The way I see it D has 2 options, provide an easy way for C++ users to 
 switch over or become D.net.  The problem is, it is extremely 
 impracticable to switch over to D because:
 
 1) Everything is already in C++.  It would take months to switch over. 
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There are 
 so many API's that companies use, it is impossible to have them all ported.
 3) Learning.  People are resistant to learning new things.  I think this 
 hurdle is easiest to jump if the other 2 are in place.
 
 The C++ option:
 
 There are several ways this could be done however all would be most 
 effective.
 
 1) Provide an easy way to link directly with C++ (preferably MSVC), such 
 that we can write in C++ an D simultaneously and without having to write 
 wrapper code.
 
 2) Provide a way to import C++ APIs that takes practically no time to 
 implement.
 
 3) Provide a wizard that will convert a C++ project to D.  It needs to 
 be so easy, you don't have to even think about it.
 
 This seems like its asking for a lot.  However a month or 2 was spent 
 setting up D so it could be integrated with C++ within a couple of 
 clicks, it would pay huge dividends.  This would mean that it would be 
 much easier for anyone at a C++ factory to convince managers of D's cost 
 befits.
 
 I think many C++ programmers are looking for a better alternative 
 however they can't switch to D because of the afore mentioned problems. 
   If this was done right, you could practically convert many of the C++ 
 community. Not unlike C++ did to C. I doubt you'll get many C converts 
 though because most of the ones remaining can't leave C for other reasons.
 
 
 D.Net option:
 

 D provides.  With products like XNA and a decent development 

 that works with net (that was in development ages ago), would give D a 
 foothold for the next generation of programmers.  I do however think 
 that D will be a harder sell on this platform.
 
 Final comments
 
 It may be possible for D to find its way into main stream by a nitch 
 market however I think the chances here are low.  Of course one possibly 
 here is the mobile phone industry.  Even so, D runs the risk of being a 
 one-time-wonder that is dependent on the phone companies continued support.
 
 Note that I discount Java because there is less overlap in 
 functionalities.  Furthermore note that my point of view is from the 
 game industry and the situation may be completely different for business.
 
 So if D wants to become big (say in the next year), I think some time 
 invested in supporting C++ is its best bet.
 
 -Joel
The main reason I am looking at D right now is that it is a systems-compiled language. It doesn't require the .NET runtime, which many people don't have (even though it's standard with Vista now) or JRE. To me, D seems like a "best of both worlds" approach that has both the features of a .NET language/Java, but with the power for direct system access and no reliance on a preinstalled runtime. "D.Net" sounds just horrible to me. This topic has been discussed to death, but I agree with the other posters in this thread. D needs (to become a mainstream language for enterprise-level development): 1. To decide on a standard library (Tango fits the bill better here, since it resembles the Java and .NET standard libraries, which many programmers today are trained in. The libraries each have their own advantages for open-source, etc., development, but Tango seems to be the better choice for enterprise development). 2. An IDE (Descent, if it manages to port as much of the JDT as it's trying to, integrates niceley with a well-known platform, and seems to be as perfect as can be for the job). 3. An easy(ier) way to wrap C/C++ libraries. bcd.gen is going places, but it's not quite there yet. 4. Documentation. 5. A book or two on it. 6. More libraries, preferably all located in a standard location and easy to install (DSSS!!!) 7. Better reflection support. 8. Better unit testing support. 9. Possibly, ideally, a wrapper that allows calling to and from Java and/or .NET _easily_. Like, really easily (transparently). Like, use a Java class in D and a D class in Java without having to write any boilerplate code at all. 10. Some big company to adopt it. There's my $0.02
Apr 23 2007
parent janderson <askme me.com> writes:
Robert Fraser wrote:
 janderson Wrote:
 
 Its about time for another round of how D can conquer the world.

 The way I see it D has 2 options, provide an easy way for C++ users to 
 switch over or become D.net.  The problem is, it is extremely 
 impracticable to switch over to D because:

 1) Everything is already in C++.  It would take months to switch over. 
 Time that no one has.
 2) Many API's are in C++.  Porting is too dam time consuming.  There are 
 so many API's that companies use, it is impossible to have them all ported.
 3) Learning.  People are resistant to learning new things.  I think this 
 hurdle is easiest to jump if the other 2 are in place.

 The C++ option:

 There are several ways this could be done however all would be most 
 effective.

 1) Provide an easy way to link directly with C++ (preferably MSVC), such 
 that we can write in C++ an D simultaneously and without having to write 
 wrapper code.

 2) Provide a way to import C++ APIs that takes practically no time to 
 implement.

 3) Provide a wizard that will convert a C++ project to D.  It needs to 
 be so easy, you don't have to even think about it.

 This seems like its asking for a lot.  However a month or 2 was spent 
 setting up D so it could be integrated with C++ within a couple of 
 clicks, it would pay huge dividends.  This would mean that it would be 
 much easier for anyone at a C++ factory to convince managers of D's cost 
 befits.

 I think many C++ programmers are looking for a better alternative 
 however they can't switch to D because of the afore mentioned problems. 
   If this was done right, you could practically convert many of the C++ 
 community. Not unlike C++ did to C. I doubt you'll get many C converts 
 though because most of the ones remaining can't leave C for other reasons.


 D.Net option:


 D provides.  With products like XNA and a decent development 

 that works with net (that was in development ages ago), would give D a 
 foothold for the next generation of programmers.  I do however think 
 that D will be a harder sell on this platform.

 Final comments

 It may be possible for D to find its way into main stream by a nitch 
 market however I think the chances here are low.  Of course one possibly 
 here is the mobile phone industry.  Even so, D runs the risk of being a 
 one-time-wonder that is dependent on the phone companies continued support.

 Note that I discount Java because there is less overlap in 
 functionalities.  Furthermore note that my point of view is from the 
 game industry and the situation may be completely different for business.

 So if D wants to become big (say in the next year), I think some time 
 invested in supporting C++ is its best bet.

 -Joel
The main reason I am looking at D right now is that it is a systems-compiled language. It doesn't require the .NET runtime, which many people don't have (even though it's standard with Vista now) or JRE. To me, D seems like a "best of both worlds" approach that has both the features of a .NET language/Java, but with the power for direct system access and no reliance on a preinstalled runtime. "D.Net" sounds just horrible to me. This topic has been discussed to death, but I agree with the other posters in this thread. D needs (to become a mainstream language for enterprise-level development): 1. To decide on a standard library (Tango fits the bill better here, since it resembles the Java and .NET standard libraries, which many programmers today are trained in. The libraries each have their own advantages for open-source, etc., development, but Tango seems to be the better choice for enterprise development). 2. An IDE (Descent, if it manages to port as much of the JDT as it's trying to, integrates niceley with a well-known platform, and seems to be as perfect as can be for the job). 3. An easy(ier) way to wrap C/C++ libraries. bcd.gen is going places, but it's not quite there yet. 4. Documentation. 5. A book or two on it. 6. More libraries, preferably all located in a standard location and easy to install (DSSS!!!) 7. Better reflection support. 8. Better unit testing support. 9. Possibly, ideally, a wrapper that allows calling to and from Java and/or .NET _easily_. Like, really easily (transparently). Like, use a Java class in D and a D class in Java without having to write any boilerplate code at all. 10. Some big company to adopt it. There's my $0.02
This is a great list! It would be nice if someday the official D site (DMD right now) would be able to list all of these on a myths page, having a really good answer for everyone. -Joel
Apr 23 2007
prev sibling parent reply NN <nn-mail bk.ru> writes:
janderson Wrote:

D gets popularity but not enough.
IMHO the main factor is the connection with other languages.
The only connection D has is via C interface which is not enough.

I think D should support COM and C API in a simple way.
Even by native language support.

This is need because D standard library is rare, but with simple COM support,
for example, D can use many Windows objects.

What about porting Boost.Python for D as starting point ?
Thus Python can easily be connected to D program and this can increase language
usage.

And of course DMD should be replaced by GDC , because 2 compilers do porting
problem.
GDC has a big advantage because the back end is same for GCC so it can get all
optimizations automatically.
Apr 24 2007
next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
NN wrote:

 janderson Wrote:
 
 D gets popularity but not enough.
 IMHO the main factor is the connection with other languages.
 The only connection D has is via C interface which is not enough.
 
 I think D should support COM and C API in a simple way.
 Even by native language support.
 
 This is need because D standard library is rare, but with simple COM
 support, for example, D can use many Windows objects.
 
D supports COM and interfaces with C just fine.
 What about porting Boost.Python for D as starting point ?
 Thus Python can easily be connected to D program and this can increase
 language usage.
There is already PyD which is probably going to kick Boost.Python's ass when it matures.
 
 And of course DMD should be replaced by GDC , because 2 compilers do
 porting problem. GDC has a big advantage because the back end is same for
 GCC so it can get all optimizations automatically.
Apr 24 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
NN wrote:
 janderson Wrote:
 
 D gets popularity but not enough.
 IMHO the main factor is the connection with other languages.
 The only connection D has is via C interface which is not enough.
AFAIK pretty much every programming language "speaks" C. It's basically the lingua franca of the programming world.
 I think D should support COM and C API in a simple way.
 Even by native language support.
 
 This is need because D standard library is rare, but with simple COM support,
for example, D can use many Windows objects.
Are you aware of the last section of http://www.digitalmars.com/d/interface.html ?
 What about porting Boost.Python for D as starting point ?
 Thus Python can easily be connected to D program and this can increase
language usage.
http://dsource.org/projects/pyd ?
 And of course DMD should be replaced by GDC , because 2 compilers do porting
problem.
 GDC has a big advantage because the back end is same for GCC so it can get all
optimizations automatically.
Having multiple implementations is a good thing. Some people (and companies) have a preference for open-source or commercial software. Some might also be hesitant to use a language with only a single compiler available. A show-stopping bug in one compiler might also be worked around by switching compilers.
Apr 24 2007
next sibling parent jcc7 <technocrat7 gmail.com> writes:
== Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article
 NN wrote:
(snip)
 I think D should support COM and C API in a simple way.
 Even by native language support.

 This is need because D standard library is rare, but with simple
 COM support, for example, D can use many Windows objects.
Are you aware of the last section of http://www.digitalmars.com/d/interface.html ?
I think NN is complaining about how difficult it is to use existing COM classes from D. It is a lot of trouble right now. I think that Juno (http://www.dsource.org/projects/juno) has the potential to make COM a lot simpler in D, but it hasn't officially caught up to D 1.0 yet, and I like to work with more current versions of the DMD compiler. So I'm hoping that Juno's author returns and updates Juno. In the meantime, another user (oldrev) came up with an update (http://www.dsource.org/projects/juno/wiki/UserContributions). I plan to use oldrev's work to come up with some more examples, but my plans often get sidetracked. jcc7
Apr 24 2007
prev sibling parent NN <nn-mail bk.ru> writes:
Frits van Bommel Wrote:

 NN wrote:
 janderson Wrote:
 
 D gets popularity but not enough.
 IMHO the main factor is the connection with other languages.
 The only connection D has is via C interface which is not enough.
AFAIK pretty much every programming language "speaks" C. It's basically the lingua franca of the programming world.
It is but still there is much C++.
 
 I think D should support COM and C API in a simple way.
 Even by native language support.
 
 This is need because D standard library is rare, but with simple COM support,
for example, D can use many Windows objects.
Are you aware of the last section of http://www.digitalmars.com/d/interface.html ?
Yes, but it doesn't helps too much. How the proxy-stub generated ? VC supports #import which simplifies your life a lot, can D do the same ? What happens if the interface in the top isn't derived from IUnknown: interface A { . .} interface B : A, IUnknown { .. }
 
 What about porting Boost.Python for D as starting point ?
 Thus Python can easily be connected to D program and this can increase
language usage.
http://dsource.org/projects/pyd ?
+1 Nice, didn't know about it :) Anyway it is a good starting point but not the end.
 
 And of course DMD should be replaced by GDC , because 2 compilers do porting
problem.
 GDC has a big advantage because the back end is same for GCC so it can get all
optimizations automatically.
Having multiple implementations is a good thing. Some people (and companies) have a preference for open-source or commercial software. Some might also be hesitant to use a language with only a single compiler available. A show-stopping bug in one compiler might also be worked around by switching compilers.
Apr 24 2007