does D already have too many language features ?

[H. S. Teoh]

On Tue, Apr 09, 2019 at 04:56:39PM +0000, Abdulhaq via Digitalmars-d wrote:
> On Tuesday, 9 April 2019 at 11:39:33 UTC, Atila Neves 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:
[...]
> > > 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.
> > 
> > Every medium to large project in a language *without* AST macros
> > already has its own private language that is poorly documented and
> > only a few of the developers really understand. It's just that this
> > DSL is in the syntax of the host language.
> 
> Yes, and writing those DSLs for that big project is often the most fun
> part.  However, those DSLs are normally tucked away in a specific
> functional area, whereas when the developer can create AST macros, the
> DSL can do crazy stuff and can be present or even required in every
> source file.
> 
> For instance, take the named parameters proposals. With AST macros
> each person can implement their own ideas. We could end up with one
> library having them one way, another library having them implemented a
> very different way with different behaviour. It would be very annoying
> if you wanted to use both libraries. Then multiply that by all the
> other unapproved DIPs.
[...]

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. You'll end up wasting a ton of time writing
shim code to convert from one OO library to another and back, and the
host application will have a "fun" time dealing with two (or more)
incompatible object types, rather than actually getting work done in
your problem domain.

Some things ought to be baked into the language, because that's where
you define standard interfaces that everyone else follows, thus ensuring
mutual compatibility between code written by different authors.


T

-- 
Let's call it an accidental feature. -- Larry Wall