On (Programming) Language Design
By: Tiago Simões
Tags: Outsystems, Perspective, Computer Science, Programming Languages

What makes us different from all other species? Well, several things. We are the only species that has a sense of humor. We’re the only ones that cry. But, most importantly, we’ve been changing ourselves and the world around us faster than any other living being.

Take a look at where you are today. You may be some meters above ground level. You can control the weather inside those walls. To go somewhere, you can take your pick from a medley of means of transportation. You have power in the form of electricity coming out of plugs in the walls. You have the Internet flowing in the air.

If you have all these, it’s because humankind has two big advantages: we are tool builders, and we have language.

Tools and Language

The pen, the airplane, the clock, the phone: tools. Aristoteles’ work on logic, Newton’s “Principia Mathematica”, Darwin’s “Origin of the Species”, Einstein’s “Theory of Relativity”: language. All human civilization was built upon tools and language.

When we think about a problem, some of us might see images, but all of us use words to think. The most common view is that language is a way for us to communicate. But it’s way more than that: it’s also a tool for us to think with higher-level concepts.

And the language itself influences the way we think. A study showed that people whose native language has no strong future tense (like German or Finish, where they say “I go to the cinema tomorrow” instead of “I’ll go to the cinema tomorrow”) save more for retirement and have lower smoking rates. People don’t distance themselves from their future selves.

There is an aboriginal tribe in Australia that does not have the words ‘left’ or ‘right’, only ‘North’, ‘South’, ‘East’ and ‘West’, so they have a far better sense of direction than everyone else.

So what a language doesn’t have is just as important as what it does have. The core of a language is not words and sentences; it’s the meaning of them in the heads of the people who use it.

Now say, for example, the word ‘pen’. A mental image of the object crops into your head, which may not necessarily be the same as the mental image of someone who speaks another language. Yet there is a universal consensus of what the word ‘pen’ represents.

The same can be said about programming languages. That’s where visual language comes in.

From Spoken to Visual

The words that make up a language do indeed affect the way in which a person processes the world around them, but it’s not the only means of referring to objects or actions. Graphic, or visual, communication is not simply aesthetic, but rather has a functional role in communicating. In programming language, that couldn’t be more obvious.

Let me give you an example. The other day, a colleague of mine was working on an application using the OutSystems low-code visual language. She looked at a timer and immediately said that it would not scale and that she needed a “heavy timer”.

A heavy timer is a pattern known by advanced OutSystems developers, where records are processed, thus committing the transaction, and, after a specified time, the timer wakes itself over again. It works like a processing queue.

So it is not part of our core visual language, it’s part of our extended language. But it’s also a tool that allowed her to spot a problem and a fix at a higher level. She saw it in her head. She heard it in her head. And then she fixed it.

Regarding programming languages, you may already know this quote:

Naming things… Language, right? But let’s focus on another one: do you know why there are so many off-by-one errors? Because arrays start counting with 0 instead of 1, unlike humans do.

Another: Tony Hoare, the creator of Algol (a precursor of C) said that null references were his billion-dollar mistake. Every time I see C# or Java code, with all those null checks, I know that’s a severe underestimation.

A last one: Why do object-oriented languages lead to messy spaghetti code? Because of inheritance and because state is spread all over. That doesn’t happen so much in our visual language as there is no inheritance.

So What’s OutSystems Doing About it?

Our company is lucky to be focused. OutSystems is not for creating websites, games, scientific research, or operating or embedded systems. Our low-code approach allows the creation of enterprise web and mobile apps. At the same time, the scope is so broad, and there is so much need for it, that if we continue evolving in the right way, we might have an impact in future programming languages and tools.

And as for the difference between language and tool: our users don’t care if something is solved with the tool or with the language. They view it as a whole. They may think “How can I solve this pain/new challenge?”, and we at OutSystems understand their struggles and needs. And we can offer a solution to solve their problem. What’s important is the whole developer experience.

So these choices matter. What we put in the tool and on the language, and how they work together, matters. It’s hard to make these calls, but it’s supposed to be hard. Because OutSystems is a pioneer in low-code, and our choices might live a lot longer than us or this company. They will be our legacy.

Designing a Tool and a Language

Programming languages were born from the bottom up as a way for people to understand, and leverage, how computers work. That view is now outdated; it should be the other way around.

A programming language and tool needs to be a way for computers to understand what humans want. And for humans to think and work collaboratively on higher-level challenges.

That’s our contribution to human evolution: making a language and tool that work together in that way is our noble responsibility.

Based on an internal presentation.