10x Development Speedup
Locality of Logic
Locality of Logic has existed as a concept for quite some time. It is usually implemented in the form of object encapsulation (object oriented programming).
The basic idea Is that a programmer only has to understand the inner workings of an object in the code that implements the object. When other programmers use the object as a building block in a larger application, they only have to understand how the objects works “from the outside” and do not need to understand the details of how the object is implemented internally.
Does not translate While this is beneficial at the object level, object encapsulation does not translate equally well to the system level.
Reduce the number of DB schemes In System Oriented Programming, both through the software run-time environment "plumbing" as well as design and implementation methodologies that are encouraged/enforced by the programming framework, the design of enterprise class applications is done with a vastly reduced number of database schemes. In System Oriented Programming, the number of encapsulations in an enterprise class application fall from 100's to typically fewer than 10 .
App logic is embedded in DB schemes System Oriented Programming dictates that application building block functionality/logic is implemented locally in a few schemes in what would be referred to as "stored procedures" in the relational database world. These stored procedures have Locality of Logic; the application logic is co-located with the storage scheme definition and typically requires knowledge of only that scheme or just one or two additional schemes.
Analog to Locality of Reference In much the same way that Locality of Reference improves computation performance by not requiring access to remote data during a calculation – Locality of Logic requires only local knowledge of a database scheme instead of knowledge of an intractable number of potential interactions between relational data tables.
Multi-model Optimizing for Locality of Logic, means that database layer code presents multiple data models and compute models to the application developer. This enables the application developer to use the data model that most “naturally” fits the part of the application the developer is working on.
Eliminating source of complexity A major cause of complexity in traditional enterprise applications, is the convoluted code that forces application data into a (relational) data storage model that may not be the most natural, intuitive, or concise way to represent the data. By making it easy for multiple data models and compute models to co-exist, the application code becomes more intuitive, expressive, and smaller. Building blocks of application logic can be embedded in the database scheme itself instead of having to sit above layers of code that massage the data into a form that is consumable at the application layer.
Development speed The reduction in complexity that results from optimizing for Locality of Logic makes application layer code significantly easier/faster to write. Empirical results show about a 10x reduction in time to develop complex applications.