>I'm not sure object oriented programming ever really caught on.
Uh they have. They were the dominant paradigm for a long time. You haven't been around long enough. I'm going to be real with you, a lot of what you say shows that you're relatively new.
>Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures?
Doesn't seem like a relation. Seems like your referring to a single table with no relationship to other tables specified.
You took a tuple and converted it to a named tuple. In SQL named tuples or named sets is the exclusive syntax... all columns are defined by name and type, all columns are queried by name. Indexed ids must be explicitly defined and in SQL they are not the default.
>Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code.
This is incorrect. First off with an orm you are implementing your datastore in two places. You define the model in SQL and redefine it in application code. There is no separation here. The orm is by definition a leak. It destroys the concept of a single source of truth.
Second. A change in schema in SQL necessitates a change in model in application code. It cannot be separate by definition. Otherwise your model in code doesn't match what exists in reality.
>String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory.
Where on earth does Json come from? No man. String manipulation is what an orm does for you. SQL databases can only operate on strings. If you don't have an orm then you are doing the string manipulation yourself because strings of SQL are literally the only interface these databases can accept.
I don't think you fully understand the mechanism at work here. Your orm is sending strings to your SQL database over a network. That is what an orm is.