Sh*tpost: can we stop saying "syntactic sugar"?

It's called syntactic sugar because it doesn't introduce any substantial new feature to the language, it's just a sweeter syntax.

So yes: destructuring and += are examples of syntactic sugar because you could write it in the longer, less clean form, and it would be equivalent.

As a side note, sometimes the verb "to desugar" is used to mean "to turn into the equivalent syntax without sugar" As in this example sentence:

a += b desugars to a = a + b

Async/await is not an true example of syntactic sugar, it's an entire new feature in the language. You can re-write async/code to use then/catch handlers but it's much more than a simple syntax transformation, it's a re-write.

In conclusion, it's called "sugar" probably because it implies it's something you sprinkle onto the language syntax to make it easier, but not a whole new set of features. Under the hood, syntactic sugar could be implemented as a transformation of the syntax tree, so the runtime engine may not even need to know about it.

And I agree with the "diabetes" argument: too much syntactic sugar isn't good, it can definitely be taken too far when it makes code harder to read instead of easier to read.

Interesting points, most of which I hadn't thought too deeply about before. I do find "syntactic sugar" has become a weasel word, much like "scripting language" is. It is often deployed as a way of belittling the value of a language's syntax choices.

I suppose by some interpretations, everything is "syntactic sugar" because we're not writing in binary. By even Landin's original usage, it's just a symbolic abstraction, and all modern languages are effectively symbolic abstractions.

While I like the idea proposed in the comments that "syntactic sugar" adds no actual features, but rather just makes the code easier to read and write, one could make the counterpoint that we never actually have "new features" by the truest definition of the term. We can replicate all imaginable behavior in assembly/binary, desugared, but nearly all of it would be too complicated for direct replication to be practical.

Perhaps some developers just use the belief that they write in a more "sugar free" language as a form of self-aggrandization, a la "real programmers use butterflies," but I'd counter that making one's own workflow deliberately harder with no actual gain is considerably more obtuse than using "syntactic sugar". (Bear in mind, that's coming from someone who spends a phenomenal amount of time doing bare-metal memory management in C and C++.)

In other words, it would be tremendously stupid of me if, for no other reason than to avoid "syntactic sugar," I built an application in C that could have been written to identical spec and goals in Python, given the fact I know both languages. Yet some coders I know will do exactly that.

By the way, that does not include projects for continuing self-education; knowing languages like C gives one a deeper working understanding of, not to mention an appreciation for, the abstractions that exist.

By the way, I'm not sure your particular choice of title is entirely constructive, mainly because you shouldn't devalue your own post by labeling it such. By the same token, you're not a bird brain or a knucklehead. Belittling yourself and your work is only useful for destroying your self-esteem and crippling your own growth.

"Humility isn't thinking less of yourself, it's thinking of yourself less." -C.S. Lewis

Never confuse a lack of knowledge with a lack of intelligence. A birdbrain couldn't have even written this article.

I'm a huge fan of syntactic sugar in C# - but its always there. In JavaScript, support is dependent on the environment unless you transpile and polyfill all of your code all of the time (at least for example the spread operator)

C# example (14 lines to 1 with proper linting):

public string Property { get; set; }

Is syntactic sugar for:

private string propertyField;

public string Property
{
    get
    {
        return propertyField;
    }

    set
    {
        propertyField = value;
    }
}

Hum...I supposed the term is more relevant to verbose languages. For example, the term is useless in Ruby where almost anything can be written in three different ways.

Taking your example of React, JSX is not a feature of JS. It's a feature of the development environment most React users work in. (You can write pure React code without transpiling but you won't have any JSX). So, in that case, it still makes sense.

defer( comment.conclusion )

I recently had an idea for a t-shirt for women with "syntactic sugar" on it - sort of an appropriation of the trend a few years ago to have "angel" on the back of your sweatpants. Anyway, when I googled to see if I could buy one someone else designed, I found one that said, "Assembly is just syntactic sugar." Probably the most extreme (and I assume ironic) assessment of what you express here.

I always interpret syntactic sugar as "unnecessary shortcuts". So a third party library that adds a layer of convenience functions on top of AutoLayout, for example. If all I think it's doing is providing some syntactic sugar, then I'll probably stay away. Why save some keystrokes and build up crutch with some shortcuts when I can just do it the "right way"?

There are so many third party libraries who's sole purpose is to decrease the verbosity of your code, and I don't really see "typing too much" as a problem I have.

You are exactly right that constructs like ++ and destructuring are syntactic sugar.

The whole idea of "syntactic sugar" is that it is something that is never required to write your code, and is 100% able to be done within the other constructs of the language. But if you find yourself needing to that other "other way" frequently, you can write a lot less code by using this "sugar" to write less code and have each line of the code you write be more meaningful.

I agree with you Jen in the sense that we might abuse of extraordinary key words to speak about simple things.

When we hear "syntactic sugar", we stop at syntactic and think of something very elaborated, a very mature concept, then moving on sugar we stop again and think "wait what, is it not supposed to be a serious concept? Why sugar? What does it means?".

Developers are some funny species, trying to put a little bit of spices on their life (you got it, spice, sugar,...) to make things more digest I guess.

But again, I think sometimes things are amazingly more obscure than they were meant to be.

One of my favorite new syntactic sugar is the PHP `$_SERVER['REFERER'] ?? $previousPage ?? null;", which means nothing if you are not aware of the null coalesce operator. Can't wait to see it in Javascript!

Yes, I never cared much for it. It doesn't add anything useful to the conversation and it will most likely be used with a condescending tone by someone who's job is to lecture you on things you already know.

I don't use the term myself, I call it by the feature name (like async/await), "the new syntax for _", or "the improved syntax for _." I just call it what it is instead of trying to dress it up.

I think it is one of those terms that is picking up in usage recently, especially in the JavaScript community. I think that leads to a tendency of muddying the original intent and having it be applied to everything new added to a language.