My two cents

[Adam Wilson]

On 10/20/17 04:04, Jonathan M Davis wrote:
> On Friday, October 20, 2017 02:49:34 Adam Wilson via Digitalmars-d wrote:
>> Here is the thing that bothers me about that stance. You are correct,
>> but I don't think you've considered the logical conclusion of the
>> direction your argument is headed. Pray tell, why must we stop adding
>> syntactic sugar? Why does their need to be an (by your own admission)
>> arbitrary limit?
>>
>> If we look at any moderately successful language
>> (C++/C#/Java/Python/etc.) you will find that all of them have
>> accumulated syntax sugar over the years at a fairly constant rate. For
>> example, C# has added point releases to it's release schedule for which
>> the express purpose is adding syntax sugar.
>
> It simply doesn't make sense to add every stray feature that folks ask for.
> Maybe some additional syntactic sugar will be added to D in the future, but
> there are way too many feature requests for it to make sense to implement
> even a small fraction of them. Some things are worth adding, but many really
> aren't. We have to say no frequently, or we'll be drowned in stray features
> to implement. And only so much can be added to a language before it becomes
> completely unwieldy. For instance, how many people are actually experts on
> C++ and understand all of its ins and outs? _Very_ few people. It's simply
> too complicated a language. Other languages aren't necessarily as bad off in
> that regard, but if you add enough to any language, it will get there. Every
> time you add something to the language, you stand the chance of improving
> some aspect of the language, but it comes at the cost of additional
> complexity. Sometimes the addition is worth that complexity, and sometimes
> it isn't.
>
> Knowing when to add something and when not to is often a tough question, but
> it's still true that you can't add everything. And inevitably, some of the
> things you leave out will annoy some people by their absence, just as some
> of the things you add will annoy some folks by being there.
>
> For better or worse, Walter and Andrei's current stance is essentially that
> if something can be reasonably done already in the language as it is,
> they're not adding a feature to do it. D is already insanely powerful as it
> is, and too often folks are looking to add a feature to the language when
> it's trivial to do it with a library solution. That certainly doesn't mean
> that nothing new is going to be added, but we have far more important
> features to worry about than saving someone from having to type a few extra
> characters because they want to use a couple of ?'s instead of typing out
> the code themselves or using a function call to encapsulate the behavior -
> e.g. finishing sorting out stuff like scope, @safety, and shared are far
> more critical.
>
> If someone has a really strong argument for why something is worth adding,
> then they're free to create a DIP for it, and if they can convince Walter
> and Andrei, it can make it into the language. But at this point in D's
> development, syntactic sugar really isn't high on the list of things that
> they consider to be of value. That doesn't mean that they're always right,
> but on the whole, I agree with them.
>
> - Jonathan M Davis
>

I never said "every stray feature" should be added. What I said is that 
"common idioms" should be added. Preferably without having to perform 
herculean feats of persuasion. And let's be honest, as a community we 
have a pretty good handle on what the common idioms are, seeing as how 
books have been written on the subject.

For example, ?? and ?. are ridiculously common idioms that we all 
perform every day in our D code. And as Mr. Ruppe rightly pointed out, 
it'd probably take about an hour each to knock together a complete PR 
for these features. But we have spent years arguing over because 
somebody at the top said "no more syntax sugar". Grammandos *adore* 
these types of proclamations because they give grammandos a line in the 
sand that they can defend at all costs. For example, in the US, we are 
taught that "ain't" is not an English word and should never be used. 
However, it has a long and storied history as an English word and has a 
specific use. But grammandos took their grammar teachers word as 
iron-clad law and have enforced it mercilessly, resulting in the death 
of a legitimate word. All because some British royalty didn't like it 
when the peasants started using the word 200 years ago.

So far I have seen three arguments proffered for the ban syntax sugar.

The first is "Walter/Andrei doesn't have the time." This is prima facie 
ridiculous as it presumes that Walter/Andrei must be the one to 
implement it. If this is the case then D dies in the same moment that 
Walter/Andrei does. Since that is obviously not the case, this argument 
can be safely invalidated by simply observing the environment in which D 
is created.

Every time I talk to Walter in-person about these sorts of proclamations 
he routinely says something along the lines of "It means that I won't be 
doing the work, but if someone wants to shepherd it through the PR 
process I'd gladly accept it." This position is quite rational, Walter's 
job is to focus on the big problems of D, not adding syntax sugar. I 
know this because I've specifically asked Walter about ?? and ?. in the 
past and his response was "So go do it. I'll accept it."

However, I think we've mistaken "I won't do it" for "It shall not be 
done." I say this because when these features do occasionally show up as 
PR's they are roundly criticized by the community grammandos for 
violating the Most Holy Laws of D. The PR author gives up, closes the 
PR, and Walter never has the chance to accept it.

Indeed, I don't contribute to D because I have little interest in doing 
the required verbal judo with the community grammandos. If I absolutely 
had too, I would open a PR and email Walter directly so that he could 
intervene directly before the grammandos can react. What I would NOT do 
is talk about it on the forums until AFTER Walter had approved it. But I 
have the advantage of being able to leverage a personal relationship. 
Our newcomers do not.

The second argument is "the language is already powerful enough to let 
you do that." This argument is specious. Yes, the language is powerful 
enough to do those things without syntax sugar. But syntax sugar isn't 
about power, it's about efficiency. So I certainly can write a function 
that does what ?. does but as we've already seen in this thread, there 
are multiple ways to name it. So far I've seen orElse and getOr. This 
creates a dialectic friction, whereby when moving to a new codebase I 
have to learn these new shibboleths. Those methods may function 
identically or they may have frustratingly subtle differences in 
implementation, and I have absolutely no way to know from reading the 
calling code.

By adding syntax sugar we standardize these idiomatic shibboleths. This 
improves the overall code read/write efficiency by standardizing both 
the language construct and the implementation of the idiom. Of course 
you are still free to write the non-idiomatic methods you need. And 
indeed, by standardizing the common idiom, it becomes trivial to 
differentiate the standard idioms from the non-standard idioms. This is 
a two-stage win for the language.

The third argument is: "syntax sugar makes the language more 
complicated." Again, specious. The correct answer is that the bad design 
and implementation of any language feature makes the language more 
complicated. A well done syntax sugar design and implementation 
significantly reduces code complexity for reasons stated in the second 
point.

D suffers from poorly designed and implemented features, which, in order 
to use successfully, require a significant amount of "deep knowledge" or 
knowledge that goes beyond what is shown in the code. That deep 
knowledge turns what should be a straight forward feature, @nogc for 
example, into book of unwritten knowledge about which language+library 
features allocate behind the scenes.

Much of the design of these syntax sugars has already been done for us. 
We know how async/await is supposed to function. We know how ?? and ?. 
function. We also know that most of these sugars vastly reduce 
complexity (and errors resulting from said complexity) because they've 
been proven to do just than in other languages for many years (decades 
in some cases). Async/Await is the perfect example of sugar that 
eliminated entire classes of threading related errors due to reduced 
implementation complexity.

Of course, you CAN implement Async methods in C# without Async/Await. C# 
is also powerful language with all the primitive tools required to do 
so. Indeed the compiler rewrites the await to IL that uses those tools. 
But why on earth would you? The code can be over 100 lines long per 
await and you will get something wrong.

Syntax sugar is a key component of any Safe language.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;