The Object-Relational Dilemma
One of the most difficult problems encountered in real-world object oriented development is the object relational impedance mismatch. Object-oriented languages are fundamentally incompatible with the relational model used by most databases.
This conflict has long plagued developers. As Ted Neward pointed out, it is the “Vietnam of Computer Science.”
Object/Relational Mapping represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy.
- Ted Neward
To list just a few of the incompatibilities between object-oriented and relational models:
| Object-Oriented Programming | Relational Model |
|---|---|
| Ties data and behavior together. | Data and behavior are separate. |
| Objects are directed graphs; references are one-way. | References are automatically bidirectional (simpler and easier to manage). |
Typically uses reference equality, a common source of bugs. Every new Java developer has questioned their sanity after mixing up == and Equals at some point. | Uses value equality, which eliminates the possibility of duplicate data and is easier to reason about. |
| Includes concepts like inheritance, encapsulation, and polymorphism. | Lacks object-oriented concepts, but the usefulness of these features is often questioned (especially inheritance). |
| Enforces integrity imperatively, e.g., getters, setters, and exception handling, etc. More room for bugs. | Enforces integrity declaratively, e.g., foreign keys, unique constraints, etc. |
These clashes force us to either bend relational models to fit OOP paradigms or vice versa. Usually, people resort to Object-Relational Mappers (ORMs), which favors the OOP mindset. But I argue that we should instead favor the relational model, as it provides a simpler, more robust framework for computation.
Why Relational Programming
The famous paper Out of the Tar Pit provides a compelling argument for a relational programming language. The paper claims that current programming paradigms are incapable of managing the complexities of large-scale software development.
The authors propose a new type of programming language, dubbed “Functional Relational Programming” (FRP), which combines elements of functional, logical, and relational programming paradigms. The paper highlights how FRP minimizes state, simplifies control flow, and employs a declarative approach to reduce complexity and bugs.
The primary, overriding goal behind the FRP architecture (and indeed this whole paper) is of course elimination of complexity.
- Out of the Tar Pit
Unfortunately, no mainstream programming language currently incorporates these principles effectively. The theory exists, but the practical tools don’t. The best effort so far is the Cell programming language, but it is relatively obscure and not actively maintained.
Not Just SQL
To be clear, I’m not advocating that we use SQL for all business logic. A truly relational programming language would not carry the limitations and peculiarities we associate with SQL.
A well-known database paper, The Third Manifesto, critically assesses SQL-based databases and emphasizes their shortcomings in aligning with the relational model:
We seek a firm foundation for the future of data. We do not believe that the database language SQL is capable of providing such a foundation. Instead, we believe that any such foundation must be firmly rooted in the Relational Model of Data
- The Third Manifesto
The authors explain that SQL databases deviate from the true “relational model” as described by E.F. Codd’s seminal work, including SQL’s allowance of null values and duplicate rows.
Hence, the need is not just for a better database querying language but a fully relational programming language free from the limitations and quirks of SQL-based systems.
The authors then go on to propose a hypothetical replacement to SQL, dubbed D to address these problems. However, once again, no mainstream version of D exists!
Are you noticing a pattern?
In addition to the SQL problems pointed out by The Third Manifesto, I would also point out SQL’s lack of arbitrary constraints. Why can’t SQL constraints like check and unique reference other tables? This would dramatically improve data integrity. But alas, it is not supported. Unless you use a trigger, but those are imperative.
On the topic of arbitrary constraints, it’s worth mentioning Datomic, a database which is more relational than its SQL counterparts and which supports arbitrary constraints across tables. Datomic is probably the closest thing we have to a practical FRP architecture today. However, its closed-source nature and strong coupling with the Clojure programming language limit its applicability.
The limitations described above underscore the larger issue: there is a gap in both the programming and database markets. We need a truly relational database that can work hand-in-hand with a relational programming language.
Conclusion
The promise of a truly relational programming language could herald a shift in how we approach software development. Such a language would address the longstanding object-relational impedance mismatch and present a more consistent, robust, and elegant framework for engineers at all levels.
The theoretical groundwork exists. What we need now is a mainstream language that implements the theory. It’s time for the software community to take the relational model seriously and develop tools that unlock its full power.
I admit that, since the concept of functional relational programming is largely untested, nobody knows for sure how beneficial it really is. But the concept is promising enough that it deserves a concerted effort. We have the hypothesis. Let’s test it.