A summary of D's design principles

[Bruno Medeiros]

On 21/10/2010 18:07, bearophile wrote:
> Bruno Medeiros:
>
>> Rather, the big benefit of the statement above would be to reduce
>> certain wasteful discussions or comments that pop-up occasionally in
>> which someone proposes some "Pythonesque" change that might benefit
>> small programs but would be crap for medium/large ones.
>
> I suggest to judge each proposed feature on its own, instead of refusing all the "Pythonesque" changes together.
>

I agree, and never suggested or implied otherwise!

My reference to Python was a lighthearted one, I did not want to make a 
generic statement about all Python features (that's why I put quotes 
around "Pythonesque"). I am not even familiar with Python, other than 
it's syntax, and in fact, the indentation-as-blocks was the example I 
has in mind when I mentioned "Pythonesque".


> A well designed tuple unpacking syntax will shorten D code and make it more readable and more handy to write, so I think it's a positive change, both for little and large D programs.
>
> As every language feature tuples too may be abused: in large programs if many of your functions/methods return tuples with five or six different anonymous fields, your program will not be much readable.
>
> Another "Pythonesque" example of change that I regard as positive for D programs of all sizes are lazy/eager array/range comprehensions. If you don't abuse them, they shorten code, make it more readable, and avoid the cluttering of brackets and parentheses typical of lambdas with map+array/filter+array functions.
>
> Bye,
> bearophile

I've just recalled another "corollary" design goal, a strictening of the 
previous one, that I would also like to see adopted:

  * If changes are of limited use to medium/large scale projects, they 
should also not be considered, even if they are not detrimental to 
projects of such scale.

The reason for this is to save work in implementing languages tools 
(compilers, IDEs, any kind of code analysis tools, etc.). It should be 
obvious to everyone that the time of the programmers working such tools, 
especially the compiler, is a very precious resource.
Indeed, Walter has already expressed his intention to not adopt features 
that are of limited use, however, how useful a feature is is very 
debatable and often not agreed upon. So what I am arguing for, in the 
point above, is that usefulness should only be evaluated in the context 
of medium/large projects.


I am not implying that the tuple features you mentioned above have 
limited use like I described. I am not familiar with those changes at 
the moment and won't comment on them now.


-- 
Bruno Medeiros - Software Engineer