Using regular UI to write code. A hoax or a marvel?

What is a programming language? Simply said it is a formal, unambiguous way to express logic. The logic is expressed as a sequence of instructions known as statements. Behind each statement there is a state machine defined by the language grammar. Language grammar is recursive by nature. This means that the state machine is complex. Depending on the statement's type the state machine can contain branches and/or loops involving the state machine of other statements.

Statements contain expressions. Expressions are the way to define conditions, making decisions and do math calculations. Similarly to statements, behind every expression there is a state machine defined by the language grammar. This automatically means that the state machine of an expression is also recursive. Recursion is fundamental for programming languages. It is in their nature. It is what makes them the choice of preference when solving complex problems. Same is true for branching. Branching allows the state machine to contain multiple paths from its initial state to its final state. When defining the language grammar what we really do is define a number of state machines known as grammar rules. The grammar rules are then used by the language parser.

What is a parser? A component that matches the program code to the state machines behind the grammar rules. If a match is found, parsing is successful. If a match is not found, a syntax error is reported. While matching the code the parser builds a tree known as the parse tree. The parse tree is the representation of the code that computers use when validating, interpreting or compiling the code. Parse trees are also referred as program trees.

To make things more clear let's take the partial state machine of a SCL statement as an example. Why partial? Because it is way to big to show here. The theory refers to it as ATN (Augmented Transition Network). Here is how it looks:

Notice the complexity!

When you look at this image what you immediately see are the branches and the recursive nature of the statements. Collectively these are known as transitions. Nodes represent states of the state machine and are linked by the transitions. So to go from one state to the next you should follow one of the available transitions. The ATN stays hidden behind the code (nobody expects that it exists) but is the base for parsing (as already said) and context code completion.

Now the question is: How do you build a regular user interface that helps you write the statements? By regular I mean an interface based on standard user controls - check boxes, radio buttons, text boxes, combo boxes, group boxes, buttons, list boxes, expanders etc. User interfaces are supposed to simplify the task, right? Well, this is not exactly the case with languages ...

To take a specific branch the user should select the type of branch first. In this example the grammar is quite rich but generally we have multiple types of statements - Assignment statement, If statement, Case Statement, While statement, Repeat statement, For statement etc. They all have different state machines and therefore need a specific UI so that the user can visually define the statement. So far so good. We will just create a dedicated UI for each of them and that's it? Said this way it seems easy but control statements (If, Case) and repetitive statements (While, Repeat, For) by definition contain other statements. This means that the UI should represent a tree of statements and each node can be one of the above statement types. The number of child nodes in this tree is not limited so the UI should support these infinitely big trees. Working with trees is generally intuitive but when the tree becomes large users start to feel the pain. It is difficult to navigate and find your way around it. Compared to code the logic is not that straight forward to understand when working with a tree. In addition every node has a number of properties that users should configure. What properties? Usually expressions that define conditions, formulas etc. but also control variables, labels, switch-case lists etc.

Wait a minute! How to represent an expression in a regular UI? Lets say that the UI allows you to work with Boolean and arithmetic expressions. But... The expression is something that could vary a lot. The state machine behind it is recursive... How to deal with this complexity in a UI? Introduce another tree? Create a list of variables/literals and operators? But what is a variable? How do we declare one? Can it be structured? How many variables do we see in the current scope (node)? What operators are supported? What is the operator precedence? How are literals presented? What functions are available? What about function arguments? How about bitwise logic? How about some language specific syntax (bit indexers for example)? How do you switch from one language to the next? Comments? Regions? Something that I cannot think of right now?

You see. With the UI approach, the complexity grows exponentially when trying to use it for coding.

Still this is how most of the robotic applications are being built today. They rely on the presumption that a UI will make the life of the user easier. The price for this is often extreme complexity, unsupportable code, countless bugs, overwhelming user interfaces and bad user experience.

The programming language is the simplest way to express the complexity of the state machine behind it. This is why we use code on the first place. It saves us the trouble of building impossible user interfaces. The language is a natural choice in every complex task. It enables automation. With the recent AI achievements it is much easier to get a code snippet from the LLM than to fight with the UI awfulness that eventually would do the same.

In my opinion the robotic industry is going against the technology with this non- realistic goal of 'saving' the user from the programming language.

In reality what usually happens is that the UI end up kind of representing a very small subset of the state machine. For example: Boolean expression that has only one variable, one literal and one operator. This makes it 'simpler' to develop but then you limit the user to only this piece of the puzzle. His hands are tied when it comes to more complex expressions.

The same is true for the statements.

Let's look at the natural languages like the English language. Once you learn how to combine words into sentences you have the best way of expressing yourself. It is easy. It is fast. You can draw a picture instead but it will be slower and more difficult to do. Then you need to explain it again with words...

Why don't we do the same with robotic languages then? Once you learn how to combine tokens into statements you'll have the best way to express your intention.

Why do we even try to find a way to work around the language? Think about it. If this was possible to do, why robot vendors still use code?

I am dealing with this exact complexity on a daily basis. Why? Because programming languages are hard to learn? So is English but we all learn it with no complains ...