A summary of D's design principles

[bearophile]

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.

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