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