5 ms·

To me it is more of as Ted Neward describes "ORM is Vietnam of Computer Science"[1] "Although it may seem trite to say it, Object/Relational Mapping is the Vie

by geodel 7y ago

To me it is more of as Ted Neward describes "ORM is Vietnam of Computer Science"[1] "Although it may seem trite to say it, Object/Relational Mapping is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy." [1] http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

mapgrep 7y ago
Ya I’ve heard this one a lot. It’s kind of funny to say and does humorously underline the complexity of the problem but people take it seriously. So to take it seriously for a second: There was no good reason to be in Vietnam; even taking the stated rationale as a given, which many people did not, it was a concern many levels removed from the actual safety or functioning of American society. ORMs in contrast achieve much more proximate goals — they solve a real problem and can measurably reduce the amount of code you have to write. It is tedious to write the same sort of SQL query over and over. Even if you prefer to use literal sql for the complex stuff (as I do), ORMs tend to be a significant win (in fewer LOC to write) on abstracting out basic queries.
- jacques_chester 7y ago
  If you haven't read that post, it's worth reading in its entirety. The title is not the entire argument.
- setr 7y ago
  Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate SQL. The first reason is the commonly provides one, and what leads us into vietnam. The latter is why people try to avoid ORMs, yet find themselves back in vietnam. What we really need is a less shitty version of SQL.
  - noisem4ker 7y ago
    Something like jOOQ? https://www.jooq.org https://www.jooq.org
    - Noumenon72 7y ago
      Ye. Static typechecking is the only thing in his list that I really care about, since you can "git gud" at SQL and not be bothered by the syntax/ordering/parser concerns. jOOQ is exactly what I want to bridge the gap between Java and the DB.
      - setr 7y ago
        The ordering is always a problem, because your logic may not follow it. Eg if your set of conditions apply to multiple queries, then you might know your where conditions before you know your select/from clauses. So instead of building up your sql string in a straightforward fashion, you need to have at minimum an abstraction that delays construction. You get lead into vietnam as almost a direct result of SQL’s context-sensitive clauses.
        spion 7y ago
        Or you could go with LINQ's approach from (x) where (y) select (z). Honestly, I think LINQ and entity framework successfully solved most ORM concerns
    - Too 7y ago
      That looks fantastic. No magic mumbo jumbo mapping, just a simple type safe sql. Both syntax safety (no need to remember which of WHERE and HAVING comes first) and type safety on all fields. It's not advertised in the examples on the front page but i also take for granted sql injections are completely impossible since all data goes into functions and are not string formatted, without the mess of having to remember the order of arguments as with prepared statements. Anyone got tips on similar frameworks for other languages than java and for other dbs.
- SomeOldThrow 7y ago
  > ORMs in contrast achieve much more proximate goals — they solve a real problem and can measurably reduce the amount of code you have to write. Why would you optimize for LOC rather than expressing the behavior you want well? In some situations sure—rapid prototyping—but that’s an odd assumption in a general case.

by geodel 7y ago

mapgrep 7y ago

Ya I’ve heard this one a lot. It’s kind of funny to say and does humorously underline the complexity of the problem but people take it seriously. So to take it seriously for a second: There was no good reason to be in Vietnam; even taking the stated rationale as a given, which many people did not, it was a concern many levels removed from the actual safety or functioning of American society. ORMs in contrast achieve much more proximate goals — they solve a real problem and can measurably reduce the amount of code you have to write. It is tedious to write the same sort of SQL query over and over. Even if you prefer to use literal sql for the complex stuff (as I do), ORMs tend to be a significant win (in fewer LOC to write) on abstracting out basic queries.

jacques_chester 7y ago
If you haven't read that post, it's worth reading in its entirety. The title is not the entire argument.
setr 7y ago
Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate SQL. The first reason is the commonly provides one, and what leads us into vietnam. The latter is why people try to avoid ORMs, yet find themselves back in vietnam. What we really need is a less shitty version of SQL.
- noisem4ker 7y ago
  Something like jOOQ? https://www.jooq.org https://www.jooq.org
  - Noumenon72 7y ago
    Ye. Static typechecking is the only thing in his list that I really care about, since you can "git gud" at SQL and not be bothered by the syntax/ordering/parser concerns. jOOQ is exactly what I want to bridge the gap between Java and the DB.
    - setr 7y ago
      The ordering is always a problem, because your logic may not follow it. Eg if your set of conditions apply to multiple queries, then you might know your where conditions before you know your select/from clauses. So instead of building up your sql string in a straightforward fashion, you need to have at minimum an abstraction that delays construction. You get lead into vietnam as almost a direct result of SQL’s context-sensitive clauses.
      - spion 7y ago
        Or you could go with LINQ's approach from (x) where (y) select (z). Honestly, I think LINQ and entity framework successfully solved most ORM concerns
  - Too 7y ago
    That looks fantastic. No magic mumbo jumbo mapping, just a simple type safe sql. Both syntax safety (no need to remember which of WHERE and HAVING comes first) and type safety on all fields. It's not advertised in the examples on the front page but i also take for granted sql injections are completely impossible since all data goes into functions and are not string formatted, without the mess of having to remember the order of arguments as with prepared statements. Anyone got tips on similar frameworks for other languages than java and for other dbs.
SomeOldThrow 7y ago
> ORMs in contrast achieve much more proximate goals — they solve a real problem and can measurably reduce the amount of code you have to write. Why would you optimize for LOC rather than expressing the behavior you want well? In some situations sure—rapid prototyping—but that’s an odd assumption in a general case.