The design principles of D (aka The D Manifesto)

[dsimcha]

== Quote from Justin Johansson (no at spam.com)'s article
> Deeply nested in the thread "Marketing of D", the creator or D wrote
> "D has design principles, but those principles are often contradictory.
> I don't see a good reason to follow a design principle out of principle
> if it destroys the utility of the language."
> For the assurance of the believers, the swaying-over of the disbelievers
> and for the amusement of the bystanders (the D-agnostics), it would be
> great to have those design principles re-articulated here.
> For my own satisfaction, I would like to know if the "D design
> principles" (whatever they are) are concert with some fundamental axioms
> from which the rest of the D language is formulated by induction or some
> other mathematically/logically satisfying instrument.
> So may I ask of the creator of D what exactly are the design principles
> of the language.  In particular, I would be very interested to hear
> whether or not the type system aspects of the language are coherent.
> Cheers
> Justin Johansson

The one that seems to resonate most strongly throughout the design of D is "thou
shalt not need to write boilerplate code".  The inclusion of features such as
mixins, properties, ranges, highly streamlined operator overloading and a template
system much more powerful than C++'s means that if you're writing lots boilerplate
code in D, there's probably a template function, struct or class of some kind that
you need to write that will do it for you.  Contrast this to Java, where
boilerplate code is so prevalent that IDE features are designed specifically to
write it for you, or to C++, where people insist that having to write tons of
boilerplate to do even the simplest thing is just the price you pay for flexibility.