3 ms·

>They shouldn't be hiding SQL from your primary language, they should be exposing the relational model to it! But this has never been their primary purpose and

>They shouldn't be hiding SQL from your primary language, they should be exposing the relational model to it! But this has never been their primary purpose and it's not what they are good at. ORMs are supposed to map the relational model into an object oriented model so that you can work with objects rather than sets of tuples. And that's exactly how people use them. ORMs incentivise people to replace simple and declarative set operations with complex procedural code operating on individual objects. ORMs are just a terrible idea - conceptually messy, hard to debug and optimise, full of needless complexity.

zzzeek 2y ago
> ORMs are just a terrible idea - conceptually messy, hard to debug and optimise, full of needless complexity. and that's why ORMs are so unpopular and entirely absent from successful production applications for the past 30 years
- taco_emoji 2y ago
  yeah I mean, isn't all of this true for ANY abstraction? Once you're off the beaten path, they're all hard to debug and optimize, they introduce extra complexity, etc. BECAUSE they are attempting to abstract away certain details This is true for an HTTP library as much as it is an ORM.
  - fauigerzigerk 2y ago
    >yeah I mean, isn't all of this true for ANY abstraction? No, it is only true for bad abstractions.
- rqtwteye 2y ago
  Are you sure about this?
- fauigerzigerk 2y ago
  All ideas that were popular for a while are basically guaranteed to be in some successful applications. That includes bad ideas.
feoren 2y ago
Exposing the relational model to be manipulated dynamically within the parent language is exactly what LINQ in C# is. That was its primary purpose. True, LINQ is not itself an ORM -- it was built to support other ORMs like LINQ to SQL and Entity Framework, which aren't as "pure" on this subject. I don't actually like the LINQ syntax that much since it's not as extensible, but its existence is proof that the C# team did in fact intend to expose the relational model to C#. Entity Framework did try to cater to the "SQL is scary, let me use objects" crowd, and that is the majority of how it's used, and that is a mistake in my opinion. But it is also very good at supporting relational algebra within C# and composing queries dynamically; ironically, it's best at it if you disable or avoid many of its features (dynamic subclassing, linked objects). Pass IQueryables around and compose them together and life is good. Updating needs work, but updates have always been a weakness for SQL too.

zzzeek 2y ago

> ORMs are just a terrible idea - conceptually messy, hard to debug and optimise, full of needless complexity. and that's why ORMs are so unpopular and entirely absent from successful production applications for the past 30 years

taco_emoji 2y ago
yeah I mean, isn't all of this true for ANY abstraction? Once you're off the beaten path, they're all hard to debug and optimize, they introduce extra complexity, etc. BECAUSE they are attempting to abstract away certain details This is true for an HTTP library as much as it is an ORM.
- fauigerzigerk 2y ago
  >yeah I mean, isn't all of this true for ANY abstraction? No, it is only true for bad abstractions.
rqtwteye 2y ago
Are you sure about this?
fauigerzigerk 2y ago
All ideas that were popular for a while are basically guaranteed to be in some successful applications. That includes bad ideas.

feoren 2y ago

Exposing the relational model to be manipulated dynamically within the parent language is exactly what LINQ in C# is. That was its primary purpose. True, LINQ is not itself an ORM -- it was built to support other ORMs like LINQ to SQL and Entity Framework, which aren't as "pure" on this subject. I don't actually like the LINQ syntax that much since it's not as extensible, but its existence is proof that the C# team did in fact intend to expose the relational model to C#. Entity Framework did try to cater to the "SQL is scary, let me use objects" crowd, and that is the majority of how it's used, and that is a mistake in my opinion. But it is also very good at supporting relational algebra within C# and composing queries dynamically; ironically, it's best at it if you disable or avoid many of its features (dynamic subclassing, linked objects). Pass IQueryables around and compose them together and life is good. Updating needs work, but updates have always been a weakness for SQL too.