Vision for the D language - stabilizing complexity?

[QAston via Digitalmars-d]

On Friday, 8 July 2016 at 00:56:25 UTC, deadalnix wrote:
> While this very true, it is clear that most D's complexity 
> doesn't come from there. D's complexity come for the most part 
> from things being completely unprincipled and lack of vision.

But that way is PRAGMATIC, don't you know about that? It's better 
to solve similar design issues in 5 places differently based on 
current need and then live with the problems caused forever after.

> Except that it is not the case. D fucks up orthogonality 
> everytime it has the opportunity.

Well, there are some things kept orthogonal. Runtime and 
compiletime parameters are not mushed together for example. But 
the situation does not improve, relevant thread:
http://forum.dlang.org/post/nkjjc0$1oht$1@digitalmars.com

> As a result, there is a ton of useless knowledge that has to be 
> accumulated.

Wanna use reflection? It's simple, just see template type 
destructuring syntax, is expression, __traits, std.traits, 
special builtin properties and functionlike-operators.

> For instance, you'd expect that
>
> template Foo(T...) {}
>
> would take a variadic number of type as arguments, while
>
> template Foo(alias T...) {}
>
> would take a variadic number of aliases. But no, 1 take a 
> variadic number of aliases and 2/ is invalid. So now we've 
> created a situation where it is now impossible to define 
> variadic, alias and parameter/argument as 3 simple, separate 
> things, but as a whole blob of arbitrary decisions.

Oh, but the current way saves 6 characters. And was what was 
needed at the time of implemeting it.