You're missing the point - your claim of "hypothesis has to be testable otherwise can be dismissed" is itself philosophical (philosophy of science). You're claiming that your claim can be dismissed.
Stories like this hit me harder after having children, too.
But they also provoke thankfulness for all I have. For a little while after I read such tragic stories, I try to enjoy the everyday life a bit more, enjoy the presence of the loved ones.
That reminds me the story of Mozart's parents. Their first 3 children died less than 1 year old. I can't imagine the despair. Out of 7 children, only 2 survived infancy.
A lot of it is simply AMD getting on newer TSMC nodes. Most of the Apple's efficiency head start is better process (they got exclusive access to 5nm at first).
> I for one don't like it when people online, with every statement, signal their personal ethics. It gets to be very tiresome and degrades my HN experience.
Ironically, buying a Tesla is nowadays a very visible political statement.
I guess this is a point where terminology matters. If you work with SQL database in an OOP language, you pretty much always do some object-relational mapping, no matter if you have a big framework or just raw SQL connection.
But this is not what people usually call as ORMs. All the "bad kind of ORM" (JPA impls, Entity Framework, SQLAlchemy, Doctrine, Active Record...) have some concept of an entity session which is tracking the entities being processed. To me, this is a central feature of an ORM, one of its major benefits. It is, incidentally, also serving as a transaction-scoped cache.
I won't of course dispute that you can have caching on other levels as well (which may perform differently, for different use cases).
Integrating cache into connection pools brings little added value since connection pools don't have enough context/information to manage the cache intelligently. You'd have to do all the hard work (like invalidation) yourself anyway.
Example: if you execute "UPDATE orders SET x = 5 WHERE id = 10", the connection pool has no idea what entries to invalidate. ORM knows that since it tracks all managed entities, understands their structure, identity.
Well, usually you want to handle it at some level - e.g. a common REST exception handler returning a standard 500 response with some details about what went wrong. Or retry the process (sometimes the errors may be intermittent)
JPA implementations have "managed entities", sometimes called session or 1st level cache which is making sure that every entity is loaded at max. one time within a transaction. Like e.g. checking user/user permissions is something which typically has to be done in several places in course of a single request - you don't want to keep loading them for every check, you don't want to keep passing them across 20 layers, so some form of caching is needed. JPA implementations do it for you automatically (assuming you're fine with transaction-scoped cache) since this is such a core concept to how JPA works (the fact it's also a cache is kind of secondary consequence). JPA implementations typically provide more advanced caching capabilities, caching query results, distributed cache (with proper invalidation) etc.
I've made an opposite progression from the op. I was a strong believer of upfront design, but now value iterative approach as you do.
For the first try, hack together something working, you'll learn things along the way, validate/disprove your assumptions. Iterating on this will often bring you to a good solution. Sometimes you find out that your current approach is untenable, go back to the whiteboard and figure out something different.