Live data from Hacker News

What ORMs have taught me: just learn SQL (2014)

wozniak.ca

251–260 of 654 posts

Re: What ORMs have taught me: just learn SQL (2014)

#251

This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…

Sometimes you just should live with duplicated code. It's OK.

Thank you! You just said something I very much agree to but never dare to say out loud.

Re: What ORMs have taught me: just learn SQL (2014)

#252

This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…

Yep. Pick your poison.

Re: What ORMs have taught me: just learn SQL (2014)

#254
post #79

Earlier quoted context omitted.

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://b…

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…

If you haven't read that post, it's worth reading in its entirety. The title is not the entire argument.

Re: What ORMs have taught me: just learn SQL (2014)

#255
post #79

Earlier quoted context omitted.

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://b…

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…

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.

Re: What ORMs have taught me: just learn SQL (2014)

#256

Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.

That's pretty much exactly how I feel. I gave a talk a few years ago about doing advanced SQL things in ActiveRecord [0]. The talk suffered I think from lacking a unifying idea and because I tried to offer something to the whole spectrum of experience (from "this is a join" to "this is how you can express a CTE/lateral join/window function in AR"), but the real unifying motivation/message was that with AR you can hav…

AR is the gold standard. AR + extended gem + Arel covers almost 100% of the problem space. For everything else, use views or set returning functions and wrap them up in AR.

Re: What ORMs have taught me: just learn SQL (2014)

#257
post #156

Earlier quoted context omitted.

Your assembly/c analogy is more akin to comparing a shovel to a mini excavator. 95% of the time you’re better off using a query builder library for the convenience rather than locking your architecture into using an ORM that will, inevitably, cause long term headaches. For the other 5% of the time, you’re just building a todo app, use whatever fancy general purpose libraries are hot at the moment.

So, SQL is the shovel, correct?

The typical language people use is imperative language where you state how to do something, while sql is a declarative language where you say what you want.

Since we are in the world of analogies, using an ORM is like taking a shovel and using it as a prop (without speaking) to explain excavator operator where to dig, how deep, how wide, what things to avoid etc. Except querying a database can be much more complicated. You might be successful with some simple tasks, but it will fall flat on more advanced things.

Anyway perhaps if databases would expose an interface and allowed you to directly write a query plan then that wouldn't be so bad? But then many people would complain that you need to know a lot ot use it, and also based on data your plan for the same data might need to be different to be fast.

Re: What ORMs have taught me: just learn SQL (2014)

#258
post #246

Earlier quoted context omitted.

Sometimes you just should live with duplicated code. It's OK.

But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives

There's a middle ground.

Micro ORMs.

Re: What ORMs have taught me: just learn SQL (2014)

#259
post #255

Earlier quoted context omitted.

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…

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…

Something like jOOQ?

https://www.jooq.org

Re: What ORMs have taught me: just learn SQL (2014)

#260

Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.

I really don't get why people feel like non-ORMs cause boilerplate. I write the same amount of code using Micro ORMS. Type safe. No SQL. Very happy.
Post reply on HN