By pointing out the obvious you miss out jumping on the bandwagon of everyone writhing in pain over how devastated they are for the environmental impact. Whenever AI is brought up you have to remind people how unsustainable it is and how it’s all about to fall apart and how the value isn’t there, among other topics. Off topic/on topic I’m reminded of death reports during COVID for particular states. When I went to go and look at the statistics of years prior to compare, they were at par if not less than the few previous years. Just an example of uncontrolled (mostly manipulative) outrage in action. I’d like to expect better of HN but I don’t: I’ve lost all respect for the moderation (dang and now tom) here over the years.
What he is (was) talking about and what you are talking about are two different things. He saw that opening scene as an introduction of a Fantastical movie. One that would continuously pit the small and insignificant man against a noble but ultimately indifferent nature that far dwarfs anything in size. It’s the kind of stuff that you get concept artists to drool over. Imagine the kind of scenes you could have with that.
The rest of the movie compared to that expectation is a creature feature with standard elements. The one you refer to is simple foreshadowing. It’s not a cause for master class labeling. The staff that made all those dinosaurs deserves that credit, as they pulled off something very brilliant.
No. The “new generation” now knows what the outcasts and the undesirables of the “old generation” felt like. The more I speak to the younger crowd the more parallels I find which just means the “default” shifted towards a society of people who don’t know a different way, but are unaware of what goes on around them. The undesirables of the old knew, but couldn’t do anything about it.
It’s like people who are bewildered when newspapers say bankers got caught having a massive orgy of some 50+ attendees in a hotel in Switzerland. There is always a party, but you’re not invited. Simple as.
I knew the Diddy party charges wouldn’t stick because the aggrieved persons descriptions sound like commonly held parties in Los Angeles with quite a lot of consent involved (and courts aren't able to parse more nuanced aspects of consent, so people are left with a reliance on mutual cooperation)
this detail isn’t as important to people as wondering if I’ve gone to an LA sex party and whatever preconception they have of that and now me
Just like those bankers, and this thread, there is always a party
I wouldn’t do this personally because the downstream code very often has to handle differences where polymorphism breaks and you end up having to query the type. Polymorphism shouldn’t be used for data, only behavior, and only in very specific circumstances. Subclassing is a different topic.
You wouldn’t do what? Have polymorphic data to begin with? I don't see how you can choose to avoid the scenario that record A has one of several possible related metadata, other than just ignoring it and allowing invalid representations
Correct. This data doesn’t meet criteria for polymorphism because insured and uninsured processes from a book keeping perspective have very distinct flows and requirements in reality. Using OOP here is a mistake. Straight forward procedural code in-flight as well as any batch jobs should deal separately with insured and uninsured data and there should be zero overlap unless we need to extract aggregate data like how many payments in total and what’s the total amount. For those situations you can use a separate domain model that distinctly deals with these queries as value objects themselves if you want to go down that rats nest.
Other top level comments covered what I wanted to say but my comment is the OG one. I deal with payments, transactions and all that with multiple currencies and other complexities. Just keep it simple and don’t use OOP for this stuff it’s the wrong tool for the job.
The primary impetus is to enforce the constraint: a billing is either insured or uninsured. Insured has additional metadata X, Y, Z. Uninsured has additional metadata A,B,C. A billing cannot be both.
If you separate them into different insured and uninsured tables, then any tables associated with billing generally needs to be cascaded into an insured/uninsured variants as well. Billing_customer and billing_customer_details now becomes uninsured_billing_customer and insured_billing_customer and uninsured_billing_customer_details, etc.
As you add more data of this constraint, everything fragments again, scaling at 2^n tables. This is similar to the async coloring problem; what you wanted is to locally fragment the data model, but instead anything that touches it gets poisoned.
Ideally the DB would let you enforce the constraint UNIQUE(uninsured.billing_id, insured.billing_id) and split-table would suffice
I’m not seeing any top-level comments that resolve this —- other than ignoring the problem altogether (let the data model encode invalid states, handle it in app code), or switching to a different database.
Letting the app code enforce these constraints isn't ignoring the problem, it's how you solve this. Your DB is never going to represent all the business logic by itself. You can also add the slightly clunky constraint it mentions if you really want.
I wouldn't do this with separate tables. I also wouldn't do this with polymorphism, or OOP in general, even if the DBMS properly supported OOP. Trying to represent these constraints by classifying things will get confusing fast.
Only the first strategy shoves it into the same table? The fundamental problem is record A can have type X Y or Z, with each type having additional metadata. You could flatten the model and have a table for each type X Y Z and query them independently, and pay the cost of duplicate schema structure and having to ensure they’re always synchronized manually (including any dependent tables), or you pluck out the common core and run into the article’s problem
I think the article alludes to the difficulty of this solution by discussing the need for invariants to be upheld when an insured patient becomes uninsured or vice versa. Different tables for each 'subclass' could be an option, but if that can change later on, you now need to move patients between the insured_patient and uninsured_patient tables and make sure you don't have duplicates.
There is no polymorphism. There’s nothing polymorphic about the 2 types of payments. And furthermore you’re likely to run into situations where you have to have both an insured amount and an uninsured amount for a given treatment/procedure. So now you’re dealing with arrays of heterogenous data.
The process for handling the two cases is distinct. This is the classic OOP issue of trying to use a Shape object to represent both Box and Sphere. Just don’t. Stick with transaction/linear code and use transforms as it makes sense for certain cases (ie, MVVM style). Handle the two cases distinctly so there is no room for ambiguity.
People get this confused and they think it can’t be simpler.
This is the video and timestamp where Bryan Cantrill goes off about how awful oracle is. It's kinda famous around here. https://youtu.be/-zRN7XLCRhc&t=35m30s
Find more discussion about it by searching for "oracle lawn mower"
