6 ms·

This is The Technologist's Mistake: "X doesn't work well in all cases, therefore X is wrong." ORMs are great for simple stuff, and most things are simple stuff

This is The Technologist's Mistake: "X doesn't work well in all cases, therefore X is wrong." ORMs are great for simple stuff, and most things are simple stuff, even in complicated applications. The best ORMs don't try to do too much and let you kick out to SQL/strings when things get gnarly. ActiveRecord is great in regard. ActiveRecord also shows you the SQL it is executing, so you know when you are getting screwed with N+1 issues (which are easy to fix) or whatever. You are foolish to use SQL for basic CRUD and simple-to-intermediate queries and you are foolish to write a bunch of cryptic fluent API code when a bit of highly-specialized SQL will do. It's not an either/or, as long as your ORM layer is pragmatic about letting you get out to SQL where necessary.

pdonis 10y ago
> The proposed alternative of adding layers I didn't see this in the article. As far as I can tell, the article's proposed alternatives are either using a non-relational data store, or using SQL directly. If anything, that will remove layers, not add them; it's the ORM itself that is an added layer.
- carsongross 10y ago
  Mmm, yeah, I was unfairly extrapolating a bit: > Encapsulate your relational queries into a Model layer... I was thinking of the people that end up having a model layer and then a query layer on top of the model layer and then a query executor layer on top of the query layer, etc.
- hueving 10y ago
  >using a non-relational data store, or using SQL directly. If anything, that will remove layers, A non-relational data store doesn't add layers up front, but you end up adding homegrown migration layers once you realize the schema you used for your documents is no longer adequate.
deleted 10y ago
[deleted]
weberc2 10y ago
This isn't his argument; he's arguing that people expect X to work for some set of cases (either because it's the latest hotness or because X's maintainers advertise it for those cases) but it ends up being more work in those cases than the proven solution. This is different from "doesn't work well in all cases".
- carsongross 10y ago
  He's arguing that ORMs break down for complex situations, so you shouldn't use them. It's a false dilemma. You can use an ORM for a lot of needs and then, when necessary, kick out to SQL. He says this "breaks the abstraction" but who cares? Abstractions aren't laws of physics: do what works. False dilemmas are the best dilemmas, because you can just ignore them. Unfortunately, programmers seem particularly susceptible to this sort of fallacy. I think it is due to a form of puritanism that I often see in the mathematical mind.

pdonis 10y ago

> The proposed alternative of adding layers I didn't see this in the article. As far as I can tell, the article's proposed alternatives are either using a non-relational data store, or using SQL directly. If anything, that will remove layers, not add them; it's the ORM itself that is an added layer.

carsongross 10y ago
Mmm, yeah, I was unfairly extrapolating a bit: > Encapsulate your relational queries into a Model layer... I was thinking of the people that end up having a model layer and then a query layer on top of the model layer and then a query executor layer on top of the query layer, etc.
hueving 10y ago
>using a non-relational data store, or using SQL directly. If anything, that will remove layers, A non-relational data store doesn't add layers up front, but you end up adding homegrown migration layers once you realize the schema you used for your documents is no longer adequate.

deleted 10y ago

[deleted]

weberc2 10y ago

This isn't his argument; he's arguing that people expect X to work for some set of cases (either because it's the latest hotness or because X's maintainers advertise it for those cases) but it ends up being more work in those cases than the proven solution. This is different from "doesn't work well in all cases".

carsongross 10y ago
He's arguing that ORMs break down for complex situations, so you shouldn't use them. It's a false dilemma. You can use an ORM for a lot of needs and then, when necessary, kick out to SQL. He says this "breaks the abstraction" but who cares? Abstractions aren't laws of physics: do what works. False dilemmas are the best dilemmas, because you can just ignore them. Unfortunately, programmers seem particularly susceptible to this sort of fallacy. I think it is due to a form of puritanism that I often see in the mathematical mind.