does D already have too many language features ?
Abdulhaq
alynch4047 at gmail.com
Mon Apr 8 18:59:25 UTC 2019
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.
More information about the Digitalmars-d
mailing list