"We dream of a world where everyone is connected through a Powerful, Singular, Live, Infinite, Open, Personal, Distributed and Accessible General Purpose Computer System. Let's start by rethinking the way we make Software."
Unit is based on a fundamental Law of Computing:
"Every software system can be thought of as a composition of input and output (IO) machines through which the data will be transported and transformed and consumed."
This can be seem as the foundation of Flow-based Programming - "data will flow through the computational graph". This principle alone can be used to define any computer program.
Unit is also heavily inspired by Functional and Reactive Programming, both highly sophisticated and wildly powerful software paradigms that confer very unique properties to the debugging experience. Aspects of Object Oriented Programming are also present on the Unit language through the presence of "objects" representing the mutable state side of programs, essential to build real life applications. The combination of these concepts can be recursed upon on the development of useful virtual tooling at an incredible speed. Unit is the product of infinitely recursing on this very own concept, with a focus on Development Experience.
The Unit paradigm was specially designed to enable easy visual creation of programs called units, which can be interacted with through their inputs and outputs. A new unit can be built by piping and collapsing together smaller units, in a process called Composition. Unit's fundamentals are not new by themselves - in fact, Unit represents a purposeful re-exploration of Computer Science principles in the context of modern Software Development.
The simplicity of programming in Unit comes from the very small number of repeatable steps which are enough to build any sort of application logic. One may start out with an initial set of units, which can be linked together and collapsed into a new graph unit. Symmetrically, a graph can be decomposed and disconnected into its set of smaller units. Moreover any software can be built by repeating this process.
The concept of a unit is essentially an advancement of the fundamental concept of a function, common to many Textual Programming Languages, such as JavaScript and C++. A function is supposed to be given an ordered list of arguments as input and it can return a single datum as output. A unit, on the other hand, can receive and send data at any time, in any order and through multiple inputs and outputs. We found that redefining the fundamental building block of Programming as a unit can exponentially reduce Software Complexity.
A code drawn in Unit is simply a Directed Graph. This is commonly the same representational model a software archictect might have in mind for understanding how programs work, or in better words, how inputs are progressively transformed into the desired outputs. This way, Unit removes steps that separate Software Architecture from Software Development. The pseudocode, the code and the program become one. Design and Development can be performed in the same place.
The conception of Unit was motivated by the observable frustration the modern programmer goes through to express even simple constructs in written code. Ideas that are easy to express commonly map to disproportionate complexity and often need to be implemented from scratch, especially when one's feeling creative, which often leads to code duplication in a global scale, leading to global waste. While the existing ecosystem provides additional tooling to support development, they come with the added cost of frequent Context Switch. The developer is constantly forced to spend time in custom "setup", "configuration", "learning" and "integration" tasks, instead of focusing on Beauty and Functionality.
Systems built on top of traditional Textual Programming Languages became so complex and heterogeneous developers lost much of their ability to understand and control their own code, rendering a weak ecosystem where every individual piece of software cannot be decomposed neither reused, much less integrated with in a plug and play manner. This is a reflex of an industry that failed to incorporate many rather fundamental principles of Systems Programming and their intersection with Cognitive Psychology.
The current state of the art of Programming imposes a tall barrier of entry for people interested in making Small Software. Reading written code is known to be error-prone and time-consuming. Such dread is further augmented by the diffculty of understanding the architecture of a program in the big picture, which is a reflex of the paradigm mismatch between how systems are encoded and how they are represented.
By making conceptually simple programs simple to express visually in Unit, the user can be quickly taught to build small useful machines that can, between many things, automate otherwise repetitive tasks, all by himself, a practice we call Personal Programming in contrast with Software Engineering, further blurring the line between User and Developer.
That brings us to the world of User Interfaces (UI), which is inseparable from the world of Programming.
Today, programming a UI is about building a thin visual layer on top of a thick black box, represented by the figure of an "app". Such apps are usually optimized, in logic and design, for a specific set of use cases, invariably rendering the UI either unfit or overfit for real life use cases, which are often unpredictable; the user is not free to arbitrarily mold the interface to his liking. He can neither extend nor extract nor focus on the objects he is currently interested on, so he's forced to content with the lack or interference of a certain UI element. This renders people hostage to the specific design decisions of many one-size-fits-all apps, which are usually borderline impossible to customize or extend.
In Unit, the (visual) components that make up a user interface are units! That means they can be composed and decomposed on will. The user can always inspect the layout and logic of anything he can put his eyes on. He can copy, extend, change, reconfigure or remove any aspect of any Unit program. Therefore, like any other unit, every unit website can be unwrapped into its subcomponents, which live side by side with the logical circuitry that controls them - no context switch between Design and Development.
Likewise, in Unit, there is no explicit separation between "frontend" and "backend". All unit processes can contain components, which helps to visualize them, and can be accessed through an array of standard communication channels. Therefore, the Unit programmer is able to debug "client" and "server" logic side by side. Nowadays, the modern divide between these technologies comes down to the presence of certain APIs, such as "HTTP", "File System" and "Database", which are always available in Unit, so the same program can run anywhere seamlessly, regardless of the host system.
Curiously, the Unit Environment is optimized for the case of 0 code. It can be used as a personal daily driver system, where the user practices no direct programming at all. The user starts out with an empty infinite canvas that can be conveniently populated with the desired units to build up the user's own reusable personal spaces.
The emergent pattern: Unit evolves by removing the divides between concepts that can otherwise work very well together: "user" and "programmer", "developer" and "designer", "client" and "server", "local" and "remote", "sync" and "async", "apps" and "systems".
Unit shifts the software paradigm in the direction of user empowerment.