D and the world

[Dan]

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.