Programming the Cloud With Persistent Data Objects


People ask me all the time why I decided to create my own language, KRL, rather than using an existing one. This is my latest thinking on that score.

Matrix Code

I've been fascinated with programming languages since I was a computer science graduate student 25 years ago. People who've grown up with object oriented programming probably don't understand the explosive, mind-blowing experience of moving from a language like Pascal or C to Smalltalk. The shear power of expressiveness was only the tip of the iceberg. Much more empowering was the new way of thinking that it engendered.

This happens because programming languages aren't technologies. Rather, they're notations. Humans have invented a lot of notations. Programming languages are just the latest examples. Programming languages have the power to shape our thinking—leading us to build new and more powerful models of the domains in which we work.

Some languages lead us to think in old, possibly even harmful ways. Others open new vistas. No one who has experienced Ruby and JavaScript or even powerful frameworks like Rails can doubt the power of a notation to shape and lead a developer's thinking.

KRL is a language that is designed to help programmers build and understand distributed, persistent data objects (PDO) that live in the cloud and interact, primarily, through events. Collections of these PDOs form what I've frequently referred to as a personal cloud. I borrowed the term "persistent data object" from the book Trillions: Thriving in the Emerging Information Ecology by Lucas, Ballay, and McManus. The term seems to describe a KRL ruleset perfectly.

Modeling a domain using event-driven PDOs requires programmers to think differently. I've seen programmers who succeed spectacularly and a few who never quite seem to get it. In the latter case, they universally failed to get into to the new model. Instead they tried to shoehorn the concepts behind event-based PDOs into their old way of thinking. Consequently, they were frustrated with KRL because it didn't behave like the programming languages that they already knew. Rather than letting the language lead their thinking and world view, they tried to force-fit it into a request-response, web-based programming model.

KRL has three important features that make it especially convenient for programming event-based PDOs:

  1. Entity Orientation—KRL is the only programming language I'm aware of that builds identity into the core of the language. While it is true that every program in every programming language ultimately executes on behalf of a particular entity, in KRL, that entity is known and built into the underlying semantics of the language. The next two features illustrate this.

  2. Rules—rules bind event patterns to actions. Event patterns are matched by event expressions. Events and actions are both extensible so that programmers are free to define events and actions that are relevant to their problem space.

    Every event is raised on behalf of a particular entity and thus a selected rule runs on behalf of the same entity. As a result, KRL is inherently multi-tenanted.

  3. Persistent Data Vales—KRL has a class of variables called "persistent variables" or just "persistents".

    There are two kinds of persistents: application variables and entity variables. Both are closed over the ruleset they are in, meaning that they are only visible to code executing within the ruleset. Application variables are stored for the ruleset and are available to any entity executing the ruleset. Entity variable values are only visible to the entity for whom they were stored. Think of application variables as roughly analogous to class variables. Entity variables are like instance variables.

    Entity variables, in particular, are a very powerful concept since they provide KRL programmers with the ability to store persistent values without the headache of configuring, linking, and using a database for most things. Because a ruleset represents a closure over its entity variables, every ruleset potentially represents a persistent data object. The Kynetx CloudOS takes advantage of this feature in implementing each of the important services underlying its overall functionality.

The concept of persistent data objects has been around for some time. For example, anyone who has used the EJB framework in Java is familiar with the concept. What is different with KRL rulesets is that they live in the cloud, are event-driven, and tied together with all the other PDOs that operate on behalf of any given entity into a personal cloud. This loose coupling of rulesets by entity gives rise to significant flexibility and power.

The vision that Lucas, Ballay, and McManus paint in Trillions is one where trillions of PDOs inhabit a real cyberspace and are linked together in vast networks. I don't have a difficult time imagining what that looks because I've seen that future in personal clouds and the PDOs that populate them. I'd be happy to give you a tour. Just contact me.

Please leave comments using the sidebar.

Last modified: Wed Feb 12 18:26:37 2020.