www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The design principles of D (aka The D Manifesto)

reply Justin Johansson <no spam.com> writes:
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
Jun 13 2010
next sibling parent BCS <none anon.com> writes:
Hello Justin,



 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.


IIRC one is: If it looks like C and compiles, it acts like C.

-- 
... <IXOYE><
Jun 13 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Justin Johansson (no 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.
Jun 13 2010
parent Michal Minich <michal.minich gmail.com> writes:
On Sun, 13 Jun 2010 18:01:23 +0000, dsimcha wrote:


 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.


Very good point IMO. By using opposite word "DRY", it could be said that 
D is designed to you keep you programs DRY, and makes it very easy and 
natural thing to do. If one finds himself repeating code, he should 
consult docs, or ask on NG.

One important thing I can think out right now is that it is natural for D 
to have safe abstractions. Either by creating them upon built-in types 
like arrays and strings or by using compile time techniques for advanced 
type checking.

Also, it might be good remind C programmers that exceptions are generally 
preferred error handling mechanism in D.
Jun 13 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hv2n35$29rl$1 digitalmars.com...

 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.


Another one seems to be "pragmatism over religious adherence". (Like 
dsimcha's, this one can be contrasted with Java.)

Also, "make the right thing easier, and the wrong thing harder".
Jun 13 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Justin Johansson" <no spam.com> wrote in message 
 news:hv2n35$29rl$1 digitalmars.com...

 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.


 
 Another one seems to be "pragmatism over religious adherence". (Like 
 dsimcha's, this one can be contrasted with Java.)
 
 Also, "make the right thing easier, and the wrong thing harder".


Nice! Also:

"Avoid magic"

"Memory safety is non-negotiable; most everything else is"

"New behaviors should be natural extensions of existing behaviors"


Andrei
Jun 13 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-06-13 19:04:25 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 "Memory safety is non-negotiable; most everything else is"


Indeed. And it'd be nice if std.algorithm and all the rest of Phobos 
and Druntime worked in  safe mode too, because currently  safe is 
pretty much impossible to use.

I don't think anyone is using SafeD at this time. I tried to use it 
once, but Phobos not being usable and a couple of compiler annoyances 
such as these two made me back off that path.

http://d.puremagic.com/issues/show_bug.cgi?id=4218
http://d.puremagic.com/issues/show_bug.cgi?id=3636

I could probably add one or two more related issues with the compiler/language.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 13 2010