does D already have too many language features ?

[bauss]

On Monday, 8 April 2019 at 22:49:10 UTC, bachmeier wrote:
> On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
>> 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.
>
> That's a valid criticism. It's also odd coming from a language 
> like D where "good code" is generic on steroids and extremely 
> hard to work with. I've been using D for six years and still 
> struggle to use Phobos at times.

And ironically nothing is stopping one from creating a language 
within D anyway.

You can basically just create a parser for your language and then 
omit D code into a mixin.

Now that would be nasty and way worse than a custom language 
using AST macros; and that's possible using D now.