BulgarianIdiot
Joined 5 years ago
Karma
1,346
Submissions
732
Member since
Aug 3
Recent submissions
Comment · 3 years ago
You win btw.
Comment · 3 years ago
The abstract concept of ORM is fine, unfortunately the particular ORMs we use suffer from pretending all objects and their relationships exist in RAM, there's a single instance of every entity and it's always up to date. An abstraction that isn't merely wrong, but falls apart in your face at every opportunity.
This problem is not unique to mapping objects to SQL databases, but mapping objects to anything remote at all, say a GraphQL or a REST API.
OOP as we presently interpret it is an inherently synchronous, reference (or handle, rather) based paradigm, that only works when all your state is local and in RAM.
This is why distributed object protocols keep failing. They'll keep failing until OOP programming reorients to use values for messages and makes references explicit, so their impact is seen and felt (and it's especially seen and felt when you reference an entity on another machine halfway around the world, in terms of lag, fragility, eventual consistency and everything).
We see hints of this with value types in Swift and .NET, unfortunately I'd say rather rudimentary so far. But it's coming. The ideal example of such a set up is Erlang. A language that Joe Armstrong has called "probably the only OOP language in the world". A statement Alan Kay agrees with (source: https://www.quora.com/What-does-Alan-Kay-think-about-Joe-Arm... ).
Comment · 3 years ago
At this point browsers are more complicated than the operating systems we had back when browser+mail was the norm.
And I bet Gmail.com running in a modern browser is more complicated than a mail client from that time.
As such, browsers are now an app platform. They don't need to ship with prebaked apps like mail. They need APIs like a powerful runtime, visualization layer, background services and notifications... and they have them.
Comment · 3 years ago
Chargeback from your CC provider/bank?
Comment · 3 years ago
I find it odd how many schema changes in modern RDBMS must be done on the whole table at once. You can split a table in chunks and recode each chunk gradually in a way which doesn't change the data in it (so no downtime) but removes dead entries like updated enums.
In a way you describe how we can emulate this process. The question is why the heck wouldn't databases do this themselves? Same with adding and dropping columns.
Consider how PostgreSQL encodes null for example, by skipping them in the row as fields, and adding them in a null bitmap in front of the row. Meaning... rows are not uniformly sized, there's no math like offset = row * rowsize + field_offset; kind of addressing for reading a field in PG where recoding some of the rows breaks the entire table.
And yet we have all those huge monolithic operations that need to be done atomically. So weird.