DIP 1026---Deprecate Context-Sensitive String Literals---Community Review Round 1

[mipri]

On Tuesday, 3 December 2019 at 22:11:22 UTC, Dennis wrote:
> Even if this DIP is a failure, we could at least try to salvage
> some lessons from it. Why is it a bad DIP?

Bad motivation and bad construction. The bad construction is
apparently that HERE docs do not actually conflict with context
free grammars and that the entire point of the DIP is moot.
That wasn't obvious to me; I was mainly thinking "I guess it's
assumed that dmd will compile faster with this?"

I think the bad motivation is more interesting, even though a
lot of this is how I received your DIP rather than how you may
have definitely meant it:

1. "Less is always better." Not stated in the DIP, but in your
defense of it here:

   reduction in language complexity is (as far as I know) always 
welcome for the usual reasons:
   - less code in dmd
   - less specification text
   - less didactic material / stuff to learn for new D programmers
   - less bug/enhancement reports
   - any tool that re-implements some part of the compiler is 
easier to make

Less should have a *point*, though. Much code, specification,
and most importantly didactic material is already written. I
have physical bound books within arms reach of me that discuss
these features. Removing the feature doesn't make these books
easier to write, it just makes it more annoying for people to
read them, as they're introduced to deprecated features. It
makes "other people's code" slightly more annoying to consider,
as you may have to update that code to remove since-deprecated
features.

Removing HERE docs doesn't create a python2/python3 or a
perl5/perl6 situation, but it still forks the language and the
old language still does not simply or automatically disappear.
I really dislike this about C++: that no matter how modern it
gets, there will be these huge carbon-dated layers of code out
there that are pre-modern and that can hardly be understood
without also learning the stuff that the modern features are
supposed to have replaced.

If a feature were to be judged a mistake, it can still be a
mistake to remove the feature later on. Less is not always
better.

2. D's problem is "too many features" -> let's remove any
feature that we can -> this DIP as step #1, remove something
that looks relatively easy to remove.

How much agreement do you think there is on the first point?

Consider the "remove ~= from arrays" DIP. It removed a
feature, and removing the feature arguably materially improved
D's options to evolve as a language, and it got a really
incensed negative response.

A human engineer can improve a machine by shutting it down,
tearing it apart, making an improvement, and putting it back
together again. This interruptability of the engineered system
is one of the characteristics of human engineering, along with
"use dry materials" and "use stiff materials", that
distinguishes it from what you might call engineering by Mother
Nature, who uses wet materials, and flexible materials, and
whose works (even if they pull some tricks like molting or
entering a cocoon) must continue to stay alive even as they
undergo radical changes in form.

A DIP can't kill D, take it apart, make an improvement, and
then put it back together again, because then all the users
will be gone. Language design is more like natural engineering
in this way.

If part of D's problems is that it has a lot of features, the
best way forward can still not be to remove them.

3. "Walter said a thing about D, but a StackOverflow comment
refuted that, so the language should change so that this
criticism is no longer true."

https://stackoverflow.com/a/7083615

Geez. Someone who thinks D has "an obnoxious amount of ambiguity"
is definitely still going to think that after HERE docs are gone.