does D already have too many language features ?

[FeepingCreature]

On Tuesday, 9 April 2019 at 18:06:27 UTC, H. S. Teoh wrote:
> It's the Lisp Curse in effect:
>
> 	http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
>
> tl;dr: when a language (or language feature) becomes overly 
> powerful, what were challenging programming tasks turn into 
> trivial one-night hacks.  This initially sounds good, since you 
> can get a lot done in very little time.  However, the secondary 
> effect is that everyone will cook their own, unique solution to 
> the problem, and none of these solutions will be compatible 
> with each other. Interfacing them with each other and with 
> other components will get drowned in endless complexity caused 
> by unexpected interactions, and nobody except the original 
> author can maintain the code since nobody else understands it 
> well enough.
>
> For example, if we were to get rid of classes and interfaces 
> from D, because UDAs, DbI, compile-time introspection, and/or 
> AST macros can easily replicate the same functionality, then in 
> 5 years there will be 15 different implementations of OO as D 
> libraries. Each will work very well as long as you only use 
> that one implementation.  But as soon as you try to integrate 
> two libraries that use two different OO implementations, you're 
> screwed, because they will be inherently incompatible with each 
> other, and will have all sorts of corner cases and exceptional 
> behaviours that make interoperability total hell for whoever 
> dares attempt it.

On the other hand, I bet at least one of those implementations 
would have working interface contracts ... ;)

With language features, you're beholden to the quality and 
maintenance of the language. Macros are hard to debug and 
improve, but the alternative is that the feature lives in the 
frontend, which is possible the one thing that's harder.

And of course, D compiler features already have problems 
interacting internally.