Why

Reinvent instead of reiterate.

Start with the Why

Every decision that has shaped the platform over the past ten years has been guided by a single core value. An itch that needed to be scratched. Knowing that reason, The Why is crucial to understanding the platform itself:

The goal of the Nabu Platform is to remove the technical barrier that exists between designing a solution and making one.

Allow me to elaborate.

The Technical Barrier

Programming was initially tightly coupled to the hardware it ran on. We wrote machine language (assembly) that at a very low level directly told hardware what to do. This required intimate knowledge of the hardware and the capacity to mentally convert what you wanted to do into the correct sequence of commands to achieve it.

Realizing that the translation into machine code could be better handled by a compiler, we created higher order programming languages that let us express what we wanted to create, rather than how it would run. This is the bottom up approach: we improved our tooling to make the lives of programmers easier.

If we look at it from the top down approach we have always had some design language . Some way of expressing ideas at a much higher level, decoupled from hardware and programming. Over time, many new ideas have been added and old ones have disappeared. However one thing has remained constant: to actually get those ideas into a runnable state required a translation into a programming language.

This translation is still a mental exercise performed by the programmer. The knowledge necessary to do the conversion, is the technical barrier.

The image only shows the design concepts for a particular usecase, not the whole breadth of available concepts. That actually highlights a small but crucial difference between the languages: you can be very productive in either business language or design language while only knowing a particular subset of concepts. To be equally productive in a programming language however you need to know most of the concepts in your language of choice.

Throw away society

Compiling a programming language into machine language is a one-way trip. We can not take that machine language and convert it back into a programming language. The same goes when we convert design language into a programming language: there is no way to convert it back.

We have collectively chosen the programming language to be the single source of truth. Design language is converted manually into programming language and that translation is versioned and historized.

During the translation process developers might run into edge cases or missing pieces of the design and go back and forth with other people in the team, or perhaps even business people directly to fill in the gaps. The answers to all their questions are encapsulated into the code and rarely backported into the design language.

I have seen numerous attempts at keeping the design language and the programming language in sync and it fails every time. Even if you somehow manage to painstackingly backport all new information learned during development to the original design documents, at some point in time a new problem will prop up that will have some impact on the existing code. The code will change but no one will update the original design language.

This means that all the design language can be thrown away. It's incomplete at best, incorrect at worst.

It is in the design language that we solve our business problems. It is there that we analyze, imagine and design. The programming language is merely a construct to make the computer understand that vision.

Lost in Translation

With each translation we risk introducing translation errors. Unwritten assumptions, vague wording or misinterpretation can quickly lead to fundamental differences. By standardizing your application on a design language that everyone understands, we can limit this form of miscommunication.

Translation also takes time. The back and forth between the people who designed a solution and those who make it is not only prone to misinterpretation, it is costly. Every bug, every change needs to be interpreted and translated, verified and tweaked.

Purpose

In the past 10 years we have seen an explosion of programming languages, each attempting to carve out a specific niche but all are susceptible to that primary problem: they do not speak the design language.

What if we had tools that could speak the design language? What if we could make design language the single source of truth to be versioned and historized? What if anyone who speaks that design language could help build the application and understand the end result?

That is the purpose of the Nabu Platform: allow you to build applications using design language .

A sufficiently advanced programming language is indistinguishable from design language.

May 10, 2019
Alexander Verbruggen