The Forgotten History of OOP

How to succinctly explain the difference between OOP and OCaps?

Led us to Eric Elliott's blog post on the Forgotten History of OOP and Alan Kay's foundational work page .

Now let's describe OCaps.

Because most systems are built with OOP tooling, and this is why they need layers of cybersecurity to remain private (and unhacked). Mark S. Miller's area of expertise is applying electronic rights to create business objects such as DAML smart contracts, that can run on a public blockchain network such as Ethereum without layers of cybersecurity to protect the business objects, these objects are known as capabilities-based or OCaps. Thus rather than developing OOP business objects, then separately layering on IAM (Identity and Access Management) at deployment time using the AWS/Azuze/GCP cloud console (applying layers of defense in depth), OCaps includes electronic rights in the business object. Due to the legacy of applications written over the past 10-20-(30) years, permissioned blockchain is the practical middle ground to maintain privacy and confidentiality required for business contracts, found in cloud-based blockchain-as-a-service.

Zcash takes objects a step further and uses cryptography to implement electronic rights page

Thus to really understand the fundamentals that underpin distributed resilient computer security we need to apply electronic rights to OOP to yield OCaps. Yet to the programmer this is far too abstract and Eric presents this example on pure functions (notice that they are immutable).

> Pure functions are functions which obey two laws: > - Given the same input, always return the same output > - Produce no side-effects The functional programming paradigm uses pure functions as the primary unit of composition: the fundamental building block we build our applications with page .