JasonKryst.Com

Sugar, Sugar! Welcome to a blog entry on the history of programming.  How does sugar fit into programming history?  A little thing called syntactic sugar.  

At work today, I had a coding review returned with a number of suggested changes to enhance my shelveset.  The one item that stuck out to me was a SQL coding standard that we have in place to fully type join statements.  In my code I had a line that was similar to the following "JOIN #Users ON ATable.AID = #Users.UID."  The comment returned was in regards to specificity of the join when a qualifier is not specified.  The company coding standards specify that we fully qualify all objects, classes and entities.  Unfortunately, I did not do as such on the SQL and was rightfully questioned.

Oddly, I even questioned myself on the meaning of an unqualified JOIN, so I did a quick look up on Stack Overflow.  I was able to quickly confirm that my code was correct without placing the qualifier in front of the JOIN statement.  And within that very Stack Overflow article I discovered the term "syntactic sugar."

The construct of syntactic sugar dates back to 1964 and has been used numerous times since.  Its concepts have been implemented into SQL, C, Perl and many others.  For the programmers out there, here are a few examples of syntactic sugar:

• Using a +=b instead of a = a + b
• JOIN TBLA ON TBLA.A = TBLB.B instead of INNER JOIN TBLA ON TBLA.A = TBLB.B

As a programmer I enjoy taking shortcuts when I can to reduce task turn around time and increase efficiency.  Of course, this might be seen as lazy, but it's important to know that deadlines are tight and need to be meet.

On the other hand, there is a term that goes against syntactic sugar.  Can you guess it?  Syntactic salt!  The ideology here is that shortcuts should be avoided at all costs. No missing terms, or identifiers at any time.  Typically you will see syntactic salt within languages such as C, C++ or even C#.  A good example of syntactic salt is where you need to use the break keyword when using case statements.

Long story short, programming can be sweet, so very sweet.  When a language is being conceptualized, syntactic sugar is an option that can be added.  This does allow for developers to take shortcuts to reduce turn around times.  Unfortunately, we need to be careful when taking advantage of these shortcuts.

Moral of the blog: Watch your syntactic sugar intake.