People also "used to" invest radioactive water and used radioactive cremes and toothpastes for health benefits in the 20's and 30's. So what's your point?
That any discussion around systems that uses some arbitrary size of tables/rows/etc is empirically disproven.
Moreover, any exaggerated example of a bygone time is unrelated, as many SQL-driven systems still exist today. I work on one such system which is much larger than the example given, and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. (No hate against ActiveRecord, I use it regularly. It just takes a lot of discipline once you hit queries of a certain complexity.)
> ... and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL.
But it was ActiveRecord that got you there in the first place, as a business, and enabled you to even build anything quickly enough to meet market demand and therefore make money. Moving to a few raw SQL statements today to improve performance is called optimising and everyone in every industry does that... _after the fact_. No one should be (pre-)optimising from day 1. That's a good place to start with an ORM.
Our industry is about balancing engineering knowledge with business knowledge and market forces: we have to accept that we can't write perfect code today otherwise you won't have a job tomorrow. You have to get up and running now and optimise later, which might look like replacing some parts of an ORM's job with an optimised SQL statement.
(And again: no ORM is stopping you from running raw SQL. You can have both. It's foolish to throw out an entire ORM and everything it gives you because, "Remember when I optimised that one statement that one time?")
Sure, both tools are great options to have in your toolbox. My bigger issue was with the claim that you can't build an application bigger than arbitrary size X without an ORM, which is empirically untrue.
I will say that there are queries that take 2-3 minutes to write in SQL where you have to bang your head into the wall to make the problem fit into an ORM-shaped box. (and vice versa)
A bigger problem are developers who haven't never truly learned to write SQL (outside of a few basic statements; akin to a React developer who never really learned Javascript)
You can limit those to code you write. But it sounds like you break also on code that you didn't write eg, libraries or modules. Of course you're miserable.
There is a plan. Don't try to make him look like an idiot who has no clue. This is dangerous. It's calculated and everybody around him has to start understat his motivations to defend themselves.
Chrome removed manifest v2. It's also missing from Chromium, which means that many other browsers now have to decide to maintain that version manually, or remove it. It is being removed from Edge, a big competitor, just because maintaining it is too much work. Removing V2 and adding V3 does a lot of damage to the users, in favor of adding power to Google's Ad services.
People also "used to" invest radioactive water and used radioactive cremes and toothpastes for health benefits in the 20's and 30's. So what's your point?
reply