does D already have too many language features ?

[Abdulhaq]

On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
>
> I think some people have discussed on the forums before about 
> how AST macros could be used to implement this (after all, 
> C++'s metaclass proposal could probably also be implemented 
> with AST macros). However, even if AST macros might be used to 
> implement OOP as a library, I think the burden of proof is on 
> those in favor of library solutions to show that they can get 
> similar performance, both run-time and compile-time, and 
> quality of error messages as the current implementation.
>
> Another option would be to keep classes, but implement other 
> OOP features like interface
> and abstract as libraries, with AST macros if needed. Perhaps 
> less disruption.

The problem with AST macros, and Walter seems to agree with this 
POV, is that every medium to large project will have its own 
private language that ripples throughout the code. Only a few of 
the developers will really understand this new language and how 
it can safely be used and where its pitfalls are. It will be 
poorly documented and a nightmare for new developers.

Anyone who has coded or had to maintain a medium-to-large lisp 
code base has experienced this.

A similar problem occurs with languages like C++ and, if people 
are not careful, D too. An overly large language like C++ drives 
teams to choose their favoured subsets of features. These change 
over time and don't play well with libraries where other choices 
have been made. It's hard for new developers to pick up if their 
previous feature set was different.