peeve no. 246 is the term Syntax Sugar

As peeves go, my personal dislike for the term "syntax sugar" doesn't register all that high. It's the psychological equivalent of making a lip twitch. And, like I wrote in the rant about the acronym AJAX, I have no trouble understanding the usefulness and accuracy of this term. It's an irrational peeve. My ire is aimed more at its connotation or implication than its denotation.

Here, what I mean by syntax sugar is "syntax that makes a programming language easier to use rather than more capable". Without syntax sugar, people could give the computer the same instructions; they would just need to work harder at achieving the necessary mindset for the translation from pseudocode to actual code. Syntax sugar is "sugar" because it makes a language sweeter without making it more substantial or filling, at least from the point of view of a compiler or language designer.

My gripe is that syntax sugar is worth more than the term implies. Syntax sugar is not empty calories, to extend the analogy. In fact, extending it further, syntax sugar is the "presentation" part of food preparation that you may have heard people harp on as being so important to the total effect. (Two foods may taste excellent together, but if you stuff 'em in a blender, gourmands may not touch the mixture with a ten-foot pole.)

Basically, the attack on the "syntax is unimportant" assertion has two flanks, one pedantic and the other empirical. First, fundamentally speaking, we know that a Turing Machine can simulate another Turing Machine. If my syntax expresses a Turing-computable algorithm, yours can too, even if the extreme case is writing a full-blown interpreter that translates my syntax to yours. So almost all syntax is syntax sugar in the theoretical computer science-y sense. All you need is the syntax of the Brainf*ck language. Clearly, we foolish humans want our syntax sugar for our algorithms.

Second, experience has proven that syntax is important, because syntax is the prime, perennial point of complaint.

• Exhibit A: using indentation/whitespace to delimit code blocks rather than braces. As syntax arguments go, this one is more pointless than most because it's about mere delimiters, but otherwise rational folks will turn into raving nutters at the suggestion that braces be replaced.
  
• Exhibit B: Perl's <> and $_ . These two little syntax entities are exceedingly common in Perl code. Both are cryptic as anything, but the sheer convenience factor more than makes up for this. Perl coders seem to almost always use them and take the resulting hit in readability. These two are syntax sugar of the purest kind, but nevertheless vital to many programmers.
• Exhibit C: Huffman-coding of language constructs. I'm not referring to true Huffman information encoding, but the general concept as employed by language designers: a construct's frequency of use is inversely related to its length or ease of use. When programmers complain about writing full anonymous inner classes in Java for GUI event handlers, they are complaining about the faulty Huffman-coding of anonymous inner classes: "why must I type so much to accomplish something that comes up so often?". A similar phenomenon is programmers who are trying to switch from the imperative paradigm to the OO paradigm, and end up creating overstuffed classes because of the "bother of creating a new class just to do minor task X" (to some extent, they may be right). A more positive use of Huffman-coding is to make the programmer work harder to do things he probably shouldn't, such as global variables. Syntax must be more than just sugar, because it affects programmers so much.
  

Syntax matters. Give me some sugar.