[civilized]

> I remember reading this essay when it first came out. To try and reword it using modern terms: The author wishes that programming languages had database persistence capabilities as 1st-class built-in syntax instead of cumbersome bolted-on API functions.

This reminds me of M/MUMPS, used by Epic to power the biggest EHR system by market share in the US.

Perhaps the big difference is that the M "database" is key-value structured. True tables are flat and do not distinguish part of the tuple as the "key" and part as the "value".

I wonder if this is the source of the oft-discussed "mismatch" between the programmer's model of data and the relational model of data. Programmers like to assign values to things, while relational DBs like to do CRUD operations on records. (This is sometimes called the "object-relational impedance mismatch" but I've always found this term silly - needlessly jargon-laden and scoped overly narrowly to the OO paradigm.)

There's clearly some kind of "isomorphism" or translation between the two models, but they're not quite the same.

Is this what ORMs are about? Translating between the programmer model of data and the relational DB model?

[CRConrad]

> Is this what ORMs are about? Translating between the programmer model of data and the relational DB model?

Pretty much, AFAICS.

With varying degrees of success.