IoT Needs a New Programming Language

— by Jane Ren and Alok Batra

When asked, what does a language mean to you? An average person would say ‘a tool to communicate’. A software engineer, on the other hand, would say ‘a tool to think’.

The tools software engineers use to ‘think’ about the Internet of People (IoP) applications (e.g. a CRM or ERP application) are Java, JavaScript, C#, C++, Python, for example.

What about the tools they use to think about – and build - the Internet of Things (IoT) applications? Are they going to be the same? 

We say not.

IoT is changing such fundamentals of software application that the traditional programming language constructs and principles are becoming impediments.

Skeptical? Ask your engineering team how much effort it’s taking them to put together a business IoT application in Java (that works). You can then either accept that IoT programming will always be hard, or question if we have gotten the right tools to even think about it yet.

Declarative Languages

The right programming language tools can be game-changing, bringing programming productivity to new highs that redefine the game – they are the steam engines of the software industry.

Enterprise Applications and SQL 

In the 1980’s, SQL transformed how applications access and manipulate data, and made scaled enterprise applications possible.

Before SQL, data used by software programs were stored as records in files and accessed via the navigational approach: utilizing “pointers” and “paths” to navigate among data records. Programming like this is procedural, not declarative. Below is Wikipedia’s explanation of the difference:

"For example, to give directions to a house, the navigational approach would resemble something like "Get on highway 25 for 8 miles, turn onto Horse Road, left at the red barn, then stop at the 3rd house down the road", whereas the declarative approach would resemble "Visit the green house(s) within the following coordinates...."

The rest of the story you already know – the declarative language SQL changed the game and brought “mass production” to data manipulations. Not only was productivity raised, when developers started to think in terms of what (the orders, the inventory, the users, etc.) rather than how (navigating file paths), enterprise applications such as ERPs, ordering and accounting systems were created.

The Internet and HTML

In the 1990’s, HTML made widespread Internet applications possible by allowing developers to describe what should appear on a webpage rather than how the control flow of rendering works.

Before HTML, many procedural approaches to programming user interface were tried, such as XWindows and nothing really stuck. The diagram in Figure-1 shows an example of a simple task to “make a window appear on the screen and draw a line inside” with XWindows. The Internet would never have reached today in such involved steps!

Figure-1

The IoT and TQL

If you do hands on IoT development, you will know exactly where IoT is today – you are writing tedious procedural instructions on how to interact with Things (open ports, receive messages, queuing them…). It is hard because the how part of interacting with Things require you to know how things work in the very fine details.

So Atomiton created TQL (Thing Query Language) – a declarative programming language for IoT applications. “Declarative” means the developer specifies whatneeds to be done with Things rather than how to do it. 

IoT versus IoP 

But you say, Java is not declarative and it worked pretty well for us so far. What is missing? 

The paradigm as changed.

Until now our enterprise applications have interacted mainly with People and groups of People. We call them the Internet of People (IoP) applications. In IoT applications Things and group of Things become major actors.

 Things behave differently from people and groups of things behave very differently from groups of people.

People learn and follow application instructions. Things don’t.

No person on Earth is born with the ability of using Turbo Tax. Apparently this is of no concern to the Turbo Tax developer, who expects all users to follow the steps he designed. Such IoP applications “instruct-and-wait” – ‘here is a box, fill out your name here and hit Enter’. Obviously some IoP applications come with terrible UX designs, we grumble but nonetheless get the job done.

In terms of the relative power here, the IoP developer pushes and the people accept. 

Things, even smart things, don’t learn this. If writing IoP applications is like herding 50 high school kids (instruct and wait), writing IoT applications is like babysitting 50 infants – the best you can do is to “observe and respond” (often in parallel).

Yes, you did tell that valve to shut, but you’d better check if it actually is shut now before you count on it.

 What does it mean for the IoT developer here? Remember in software engineering, there is the development time and the run time. The developer sits in the development time and actors sit in the run time. If the developer does not have enough leverage to instruct and expect to be followed in run time (the future), nor has enough foresight to predict how exactly the actors will behave in run time, his job becomes much, much harder. If you have one single thermostat to work with – fine, iterate through all the possible scenarios. But if you have a factory floor, it is a different game.

People make contextual decisions. Things don’t. 

Every person on Earth is born with the ability to work in groups, and function in complex, chaotic, and evolving systems such as our workplace. The addition of software applications (especially workflow software) did not paralyze us (luckily) because we maintained our autonomous “local” decision-making. 'DocuSign is asking me to sign this document ASAP but that customer just submit an urgent ticket from the support system.' 

Even if bombarded with 10 different workflow applications, people can deal with innumerable contextual situations by relying on a small set of simple rules such as: customer is the most important.

Things do not come with this intelligence. Unless they are designed to work in predicted, perfectly fixed environments (such as in control systems), they fail as groups in ad-hoc situations.

A different software paradigm

Down to the programming language and programming logic level, applications in TQL are written to be parallel, asynchronous and distributed, not sequential, synchronous or centralized.

Software development in Java, C#, C++, JavaScript, Python, etc. is often written as a sequence of instructions – do this and then do that (see the previous example of XWindows versus HTML).

This sequence is at the same time, both the sequence of the program, in which you would read and reason about it, and the sequence of the execution – how real events are expected to happen in run time. It worked fine in IoP.

With things, especially groups of things, such run time sequence of interactions is in no way to be predicted or dictated by the developer sitting at his desk (the 50 infants). If you write your program in sequential instructions, it is bound to break when it runs.

What an IoT application must do (just like dealing with the 50 infants) is to take in parallel messages, run parallel logic, stop trying to sequentialize every event, and respond on the spot.

Java does not provide the fundamental framework to think in this way. TQL does.

Programming logic is also centralized in conventional applications. The developer, as the “benign dictator”, is orchestrating how the whole system of activities is going to play out. It worked fine for IoP, because people add their own contextual decision-making and adapt to the system.

In IoT, because things do not come with this intelligence, the application must provide “local” distributed logic for things. Rather than saying “let there be light”, the IoT application logic should read: ‘as a stirring motor, I always turn on for 2 hours when the clock tells me it is 8 AM. During working time, if someone else with the security key tells me to do something, I create a queue and report to everyone in my queue every 10 minutes, except if it is an emergency shut down. I don’t know anything about what is going on in the larger universe, but my life is pure and simple.’

And then the developer would go on and write code separately about the heater and the valve.

Such distributed logic will never work in sequential and synchronous software systems, which is what most current programming paradigms tell us to do. 

When a developer writes an application in TQL, on the other hand, he does not worry about synchronizing the execution. TQL programs declare what are the rules of interaction for each unit, and let them be synchronized at run time by run time events.

Language is the vehicle of thoughts. Learning to program IoT is learning to think in a different way – parallel, asynchronous and distributed.That’s why we created TQL (Thing Query Language) for software engineers who are moving to the IoT paradigm.

This video explains it.

Atomiton provides a TQL IoT Course (TQL101). This is a fast-track program to bring qualified software engineers up to speed on TQL, so they become IoT development leaders in their respective domains. Read more here.

You can access TQL from tql.atomiton.com. Many software engineers have learned and mastered it. And if you are ready for the details, here is the technical documentation site.