Nope. If it works and it's stupid, it's still stupid.
Just because companies can get stuff done in dumb ways doesn't mean those ways aren't dumb, it means that by brute force, sunk cost and obstinacy they can make things happen. There are any number of technical and non-technical dumb things in any large organization. You definitely can't assume something isn't dumb just because a company does it.
Noone is looking down on ORMs because they work, people are looking down on them because they don't work well enough to justify their downsides in most use cases. That's why people call it an anti-pattern. Yes you can get it to work but in general it's going to make things worse not better.
Now are some things that people call "anti-patterns" actually the right thing in certain circumstances? Absolutely. Just because something sucks in one situation doesn't mean it isn't the right choice in another.
> Nope. If it works and it's stupid, it's still stupid.
Successful businesses with successful and profitable products say otherwise.
The fact that stuff gets done means that it's not dumb, at a base level. You may not like it - and a lot of people don't because it removes the need for overengineered, oversmart and other "solutions" when sometimes the best solutions is literally the "stupid" solution.
> Noone is looking down on ORMs because they work, people are looking down on them because they don't work well enough to justify their downsides in most use cases.
A decade of experience in a few companies I've worked at and every company I interview with says otherwise. EF is top notch and removes a large swath of "boilerplate" code and works more than well enough.
I've had much better experiences with something like EF than I have with stored procedures and triggers and other "better" solutions.
> Now are some things that people call "anti-patterns" actually the right thing in certain circumstances? Absolutely.
See? you even admit that "anti-patterns" are the right patterns "in certain circumstances". The only thing you disagree with is how common those circumstances are and for the vast majority of circumstances? ORMs are a lot better than "custom" layers underneath.
Nothing worse than creating a custom way of doing something that's already done. Inserting your own bugs. etc.
Smart programmers don't solve problems that are already solved. I wouldn't create a PDF parser from scratch (outside of learning excercises). I wouldn't create a Word Document parser. XML parser. etc...
Why would I create a data layer management package when I have better things to do with my time that actually adds value to a company?
Just because companies can get stuff done in dumb ways doesn't mean those ways aren't dumb, it means that by brute force, sunk cost and obstinacy they can make things happen. There are any number of technical and non-technical dumb things in any large organization. You definitely can't assume something isn't dumb just because a company does it.
Noone is looking down on ORMs because they work, people are looking down on them because they don't work well enough to justify their downsides in most use cases. That's why people call it an anti-pattern. Yes you can get it to work but in general it's going to make things worse not better.
Now are some things that people call "anti-patterns" actually the right thing in certain circumstances? Absolutely. Just because something sucks in one situation doesn't mean it isn't the right choice in another.