Relational Programming

Back in the dark-ages of computing we all had a hierarchical database with which to store our precious information. It was known as the file system. Then efficiency became vogue and organizational demands moved everyone to explicit database applications (client-server model, of course). Eventually, the long-festering and ubiquitous sore of inherently non-hierarchical data in combination with the prophets of higher learning revolutionized the way in which we think about our data. Thus was created: The Relational Database.

Meanwhile, over in Software Engineering land, we’ve moved from punched cards and mentally computing address offsets through the grand era of Structured Programming and have finally landed, and fully-embraced, the Object Oriented model of software architecture. Most of the intellectual effort expended within this paradigm is on building object hierarchies, and worrying about maintaining encapsulation, and getting the right and proper amount of inheritance without violating the Liskov substitution principle.

Does this seem backwards to anybody? The Database world has progressed beyond the hierarchical model because of a realization that real-world data does not conform to a hierarchy, while all the software developers continue to struggle to model the world with inheritance hierarchies. And the more we force this model in our software design the more perverse the problems become, and pretty soon “friends have access to each other’s private members.”

We need to break the mold and democratize our objects! They need to be individualized, not just anonymous members of a large hierarchy. I believe that maintaining the strict inheritable and environmental constraints is holding the industry back. The time has come for Independence! Our objects should be promoted to full fledged processes. This is the philosophy of Erlang. Too much memory and processor time is wasted on the construction of even a Thread at the OS level, so concurrency must be implemented by the language itself. It should be trivially easy to create and destroy processes in the thousands, calculating en-mass at the whim of the programmer. To achieve this lofty goal, each process must be independent from others, no inheritance of environment, and no shared memory. Of course all this works much more naturally in a functional language, which already gets the programmer thinking about functions and first-class citizens. Now they become honored as processes.