Can Syntactic Sugar be Nutritious?

When it comes to nutrition and food, there is nothing that we vilify more than sugar, as we find out how wrong we were with fat. As programmers, we often poo poo syntactical sugar, but two interactions that I witnessed reminded me look deeper.

The two stories were of Kotlin and ES6.

Once you kot, you can’t stop

Let’s start with Kotlin. There has long been excitement with the language, and when we announced our support at Google I/O there was a huge cheer, as this signaled that, not only will we not be doing anything that could harm Kotlin support, but that we would invest in making it great. Java isn’t going away, but everyone knows they can safely dig into Kotlin. I would go even further and say that you should at least be playing with it. Many top apps have been using it in production for some time, but if you aren’t quite ready for that, look for other areas to get your feet wet such as writing unit tests to get a feel.

Pat still wasn’t sold. Why bother with a new language? Functionally what can it do that can’t be done with Java? What about finding knowledgable engineers? Or the fact that we don’t have as much documentation for it yet? At a high level this is logical, but then something happened. Pat tried it, and after a weekend of hacking with Kotlin realized how productive and fun it was. As often happens, the expectation bar rose and it meant that going back to the verbose Java code seemed…. old fashioned. Less code, fewer NullPointerExceptions, and new libraries got the juices flowing in a new way, and it didn’t hurt that Android Studio was a nice helper along the way.

I don’t need no stinking classes

Devyn saw ES4 come and go. After years of working with JavaScript, with The Good Parts on the office desk, the notion of prototypical inheritance was a huge feature, and there was no need for class syntax.

CoffeeScript came around, and although Devyn actually liked many of the features (arrow functions, the role of spaces, rest…, lexical scoping) they never seemed worth the cost.

Then we started to see changes in JavaScript itself via ES6/2015, and Devyn was still skeptical. Do I really want to use babel in my flow and set things up for older browsers? Once again, a coworker pleaded with the TL to give it a go on a small project. Fast forward a couple months and Devyn is one of the biggest proponents on the team. When asked why, a huge turning point was the road from callback city, to promise mountain, to async/await lake. Finally, it was all making sense.

const makeRequest = async () => {

  try {

    // this parse may fail

    const data = JSON.parse(await getJSON())

    console.log(data)

  } catch (err) {

    console.log(err)

  }

}

Say what you mean

All of this was wrapped up in our project’s mantra: “say what you mean”. —Alex Russell

With this cleanup, we are moving developers closer to the point where they can cleanly say what they mean, without scaffolding getting in the way. Gone is some of the verbosity, and we can huffman encode things that we use all the time.

• Don’t function make me function in my function chain
• With custom elements we can get away from div div div divitis
• Not having type information shoved in your face all the time gives your code space to breath (Dion (a Person) went home (a House))

It turns out that paper cuts really do matter. Speaking of types, one area that ES2015 has stopped short on is optional types, leaving room for TypeScript to become yet another example of something that many developers thought they didn’t want. Casey thought types only get in the way, and pattern matched “types” to “the way Java does types” (static, strong, and traditionally in your face), which happens far too often.

We have had myriad attempts of adding types in a variety of ways (beyond ES4). The Closure Compiler was one version, which has always been a phenomenal tool (to this day it normally beats the pants off of other tools when it comes to final code), but I always did a lil body shake when seeing context in comments:

/** @const */ var MY_BEER = ‘stout’;

/** @typedef {(string|number)} */

Pragmatic. But I admit to a preference of getting optional types into the language itself. Ideally even without type erasure!

One of the features in TypeScript that really tickles me is String Literal Types which allow you to get the benefit of enum without having to create enums.

String literal types allow you to specify the exact value a string must have. In practice string literal types combine nicely with union types, type guards, and type aliases. You can use these features together to get enum-like behavior with strings:

type Easing = “ease-in” | “ease-out” | “ease-in-out”;

Language features can often get rid of the need for more verbose patterns. These allow you to get around, or change fashion.

One fashion that comes to mind was when fluent APIs hit the scene hard with the growth of jQuery. I often like the way a chain looks, and they are very natural in the functional world, but when writing an API that has `return this` throughout feels a lil bit smelly to me at this point.

Dart fixes the itch without you needing to return this. Their cascade feature gives you the same flow and ability to ditch the object name shouting at you:

querySelector(‘#confirm’) // Get an object.

  ..text = ‘Confirm’ // Use its members.

  ..classes.add(‘important’)

  ..onClick.listen((e) => window.alert(‘Confirmed!’));

// and with nesting

final addressBook = (new AddressBookBuilder()

  ..name = ‘kris’

  ..email = ‘kris@example.com’

  ..phone = (new PhoneNumberBuilder()

    ..number = ‘123–456–7899’

    ..label = ‘home’)

    .build())

  .build();

Is this all nitpicky? Do you enjoy being on the flip side once you get there?

On the one hand, the hard part isn’t the syntax. If you understand the Android lifecycle thoroughly, you are good to go… picking Kotlin will be a (fun) breeze. On the other hand, your language is your expression, and you live with it for hours a day.

As I become more curmudgeon-y with age, I am trying to remember: at least give something a try before I come to a strong held belief.

I am much happier to have modern ES6/TypeScript, Kotlin, and Dart 2.0 to play with in 2017, and I look forward to more improvements, and richer support, in 2018. Some sugar over the holidays is OK isn’t it?