One of my biggest career pet peeves as a software developer is when I see other developers derisively write “Well, that is just syntactic sugar“ in response to a proposal for improving a programming language.
So today I want to write in defense of this often maligned underdog, and explain why syntactic sugar not only should not be scorned but it is instead that the type of syntactic sugar that exists is one of the more important considerations when selecting a programming language.
Or as a friend of mine would often say “Besides that Mrs Lincoln, how was the play?”
But before I go on let me say what I am advocating for is well-designed and well-vetted syntactic sugar that solidly addresses well-known use-cases, and not just any old whim some random developer has an idea for.
It can improve clarity
Good syntactic sugar can significantly improve clarity. A one point in time the venerable foreach loop — now found in different dialects in many different modern languages — was considered syntactic sugar because you could of course do the same thing with a for loop where you manually need to set and then increment an index variable.
It can eliminate entire classes of errors
Syntactic sugar can, when applied to the right problems, can minimize and/or eliminate certain class of errors. Consider again the venerable foreach loop and the magnitude of “off-by-one” errors that eliminated by software developers allowed to use it instead of being required to use the lower-level for loop.
It can minimizes maintenance requirements
This is probably the most insidious problem that syntactic sugar can address, the difficulty of maintaining a program that, by definition was either developed by a different developer or long enough ago that many aspects of the internal code have been forgotten. Now add to that the need to understand code that is less clear that it could be. This adds up to a problem.
Thus is lack of a requested syntactic sugar results in software that is harder to maintain then IMO it is hard to justify its exclusion, especially if said feature can minimize the need for future refactoring.
It can increase productivity
It should come as a forgone conclusion that if a syntactic sugar can eliminate the need to thinking through an algorithm and also can eliminate certain classes of errors that syntactic sugar can increase, and potentially significantly increase programmer productivity.
Assuming that said syntactic sugar does not negatively impact performance, isn’t that almost the entire reason we have programming languages to being with? Otherwise why are we now all still programming in assembler?
It can make programming feel “fun”
Scientists have effectively proven that using one’s brain depletes one’s physical energy, and solving low-value problems again and again can feels tedious and for smart people can be very demotivating.
So although “fun” is probably the most subjective of justifications, a good syntactic sugar makes programming feel like less effort, and thus allows developer to feel like they are having more fun when programming. And it would seem intuitively obvious that people of all stripes would gravitate to tasks that are more fun vs. less when given the option.
It can increase language adoption
Which brings us to programming language adoption. The people I have seen most often argue against syntactic sugar are the very developers who would likely end up having to implement it so to them “syntactic sugar” represents a negative.
However, if those same developers consider ever-greater adoption of their programming language a positive then I posit they would do best to reconsider their aversion to “syntactic sugar” and embrace it rather than deride it.
P.S. In offense of bad syntactic sugar
But not all syntactic sugar is good. Many things that could be consider syntactic sugar fly in the face of the reasons you should want to add said sugar. Generics, for example.
tldr;
Do not argue against syntactic sugar in it’s own right because good syntactic sugar can make for much better programs.
Instead argue against bad syntactic sugar, meaning changes to a programming language that makes source code less clear and harder to maintain, makes coding more error prone,and that adds tedium to the task of programming.
Ask these questions
So when considering syntactic sugar:
- Will it clarify code?
- Will it minimize errors?
- Will it simplify maintenance?
- Will it improve productivity?
- Will it reduce mental burden?
- Will it increase adoption?
- Will it diminish code clarity?
- Will it increase likelihood of errors?
- Will it complicate maintenance?
- Will it reduce productivity?
- Will it increase mental burden?
- Will it lessen adoption?
If for any given syntactic sugar proposal the answer is “yes” for at least several of the first six (6) questions and not “no” for any of the remaining six (6) questions then — at least in my opinion — the proposed feature should be a slam-dunk for addition to the language.