"We dream of a world where everyone is connected through a Powerful, Singular, 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."
This forms the base of Flow-based Programming; as a Programming Language, unit is also heavily inspired by Functional and Reactive Programming, a highly sophisticated and wildly powerful Software Paradigm that can enable people to build useful virtual tooling incredibly fast; unit is the product of infinitely recursing on this very own concept, with a focus in 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 iterative application of a very small set of principles. One may start out with an initial set of units (Units), which can be tied together (Connection) forming a new graph unit (Composition). Symmetrically, a graph can be decomposed and disconnected into its set of smaller units. Moreover any software can be built by repeatedly taping into those.
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; a function is supposed to be given an ordered list of arguments as input and 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 believe 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 desired outputs. This way, unit removes steps that separate Software Architecture from Software Development; the pseudocode, the code and the program become the one thing; Design and Development can be done 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. 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" 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. We believe 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; a reflex of the paradigm mismatch between how systems are encoded and how they are represented, which we believe is a strong reason why today people would avoid making sense of how software is built.
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, being that copying, extending, changing or removing. 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.
...