There are some languages, like Smalltalk and MUMPS, that try/tried to do this. In the 1990s and early 2000s you also had the emergence of object databases. Dat

There are some languages, like Smalltalk and MUMPS, that try/tried to do this. In the 1990s and early 2000s you also had the emergence of object databases. Databases like POET, Versant, Objectivity/DB, Matisse, Gemstone, ObjectStore, etc. surfaced together with the advent of object-oriented development in the late 1980s, and for a few years in the 1990s they seemed to be the future of databases. They were based on the idea that in a sufficiently powerful OO language, you could treat all your objects as transparently persistent, and use direct references to other objects to build your "object graph" instead of primary keys and joins. So you'd do something roughly like: tx = db.newTransaction() person = Person.find(tx, "123") person.setName("Bob") person.getEmployer().setBoss(person) tx.commit() The magic would happen behind the scenes. Some, like POET's Java SDK, had a command-line tool that, when you ran on your generated .class/.jar files, would take the bytecode and insert automatic persistence glue. (Some, like GemStone, were actually written in Smalltalk.) This glue had to rely extensively on lazy-loading proxy objects. For example, the employer would not be fetched until you actually called a method on the return value of person.getEmployer(). But it meant you could do something like person.getEmployer().getBoss().getAssistant() etc. and the entire graph would load as needed. What was neat about object databases was precisely that you just wrote programs that interacted with state, and the state was automatically read and written in the background. All the best object databases had ACID transactions, requiring that you actually use transaction boundaries in the code, although I believe they typically allowed pure reads without an explicit transaction object. The database was also free to cache objects heavily, relying on a stream of invalidation messages from the server to keep the cache up to date. These databases fell out of fashion for several reasons. SQL had already won back then, and these databases initially didn't have an SQL-like query language for ad-hoc queries — you had to write code to even look at your data. Whereas SQL lets you aggregate collections of data with joins and get flat tables out, the same code with an object database would typically rely on loops and recursive traversal of the object graph. OQL eventually materialized as an SQL competitor, but it was too little too late. There were other annoyances, such as the reliance on code munging or code generation, which was ultimately really specific to your programming language and platform. Doing schema migrations without the DDL statements you get with SQL was another pain point. As I remember it, the usual way to do migrations in these databases was to define new fields and write the code to write the new fields from the old ones. Some of the databases, like Matisse, had GUI tools to let you work with schemas. I still see object databases as something that could be done right today. For many of the applications we use relational databases and SQL for today, the data doesn't benefit greatly from being relational. Most web apps are in fact based on object-type graphs of entities, and rely on ORMs in order to bridge the famous "impedance mismatch" between relational data and objects. Document-oriented databases like MongoDB and Firebase are object databases without the transparent persistence. I think Microsoft's LINQ had a lot of good ideas in terms of trying to marry the computer language and the data. In my current work, I use GraphQL heavily as way to exchange data between frontend and backend, which is a bit like LINQ if you squint hard enough, but the language integration isn't nearly as cohesive. For a current project, I'm experimenting with using JSON Schema to express the shape of the data (including validation of the persistent data), then generate the GraphQL schema from that. JSON Schema's data types map to GraphQL's, so there's no lossiness, although GraphQL is more restrictive on things like union types. As long as one sticks to a subset of JSON Schema, it goes really well. It's a reasonably crutch until we get the next generation of tools, which I hope will be more similar to how object databases work.