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;
