Figuring out programming for the cloud


In the last dozen years or so, we’ve witnessed a dramatic shift from general purpose databases (Oracle, SQL Server, etc.) to purpose-built databases ( and counting). Now programming languages seem to be heading in the same direction. 

As developers move to API-driven, highly elastic infrastructure (where resources may live for days instead of years), they’re building (IaC). But how to build IaC remains an open question. For a variety of reasons, the obvious place to start was with imperative languages like C or JavaScript, telling a program how to achieve a desired end state.

But a new model of declarative languages — like  from  or from — has emerged, where the developer tells the program what the desired end state is, not overly worrying about how it gets to that state. Of the two approaches, declarative programming might well be the better option, resulting in leaner, safer code. Let’s look at why this is.

The why of declarative programming

When I asked Sam Scott, co-founder and CTO of Oso, whether we really needed another programming language, his answer was “yes.” The longer version: “With imperative languages there is often a mismatch between the language and its purpose; that is, these languages were designed for people to build apps and scripts from the ground up, as opposed to defining configurations, policies, etc.”

Introducing new, declarative languages like Oso’s Polar may actually save us from language proliferation, Scott went on: “It’s not just about introducing another language for solving a specific set of problems. Rather, it’s creating something to avoid people from having to invent their own language time and time again to do some form of embedded logic.”

Take, for example, the JSON code written for AppSync authorization:

to this.

  • Workflows. is an interesting example of taking what would have previously been done in a diagrammatic workflow language and bringing it into a more general purpose programming language format.
  • Just enough freedom, with simplicity and safety

    The trick, says Rosoff, is to give the programmer enough of a language to express the authorization rule, but not so much freedom that they can break the entire application if they have a bug. How does one determine which language to use? Rosoff offers three decision criteria:

    • Does the language allow me to express the complete breadth of programs I need to write? (In the case of authorization, does it let me express all of my authZ rules?)
    • Is the language concise? (Is it fewer lines of code and easier to read and understand than the YAML equivalent?)
    • Is the language safe? (Does it stop the programmer from introducing defects, even intentionally?)

    We still have a ways to go to make declarative languages the easy and obvious answer to infrastructure-as-code programming. One reason developers turn to imperative languages is that they have huge ecosystems built up around them with documentation, tooling, and more. Thus it’s easier to start with imperative languages, even if they’re not ideal for expressing authorization configurations in IaC.

    We also still have work to do to make the declarative languages themselves approachable for newbies. This is one reason Polar, for example, tries to borrow imperative syntax.

    Given the benefits of a declarative approach, however, it may simply be a matter of time until they become standard for IaC.

    Copyright © 2020 IDG Communications, Inc.