On: The Law of Leaky Abstractions

[marcosdumay]

The main problem with ORM is not that they are a leaky abstraction. It's that for any minimally complex problem they are a bad abstraction.

Abstractions usually empower their user, ORMs remove power.

[captainbland → marcosdumay]

To be fair, most database accesses many people are going to be doing aren't even minimally complex and having an ORM saves you a lot of tedious, boring, potentially error-prone work in those cases.

This shouldn't stop developers from actually writing a SQL query if the task at hand warrants it and using an ORM doesn't usually stop you from doing that.

[ryanbrunner → marcosdumay]

Good abstractions allow themselves to get out of the way when necessary. There are for sure bad examples of abstractions, but there's also plenty of ORMs that let you bypass the abstraction completely when needed (or use the parts of it still applicable).

I also don't really understand your last statement. Abstractions, pretty much by definition, never allow you to do more than the underlying technology they're abstracting. They necessarily limit power in order to make code more comprehensible and maintainable. That's true for any abstraction I can think of, leaky or not.

[sarchertech → ryanbrunner]

In addition to getting out od the way I prefer when an ORM allows me to extend it to build my own abstractions.

For example in Rails when I have a complicated query, I can make write some SQL, stick it in a view, and make a view backed model.

Then I can keep using Active Record to make it easier use the query in multiple places, easily compose additional queries etc...

[kyberias → marcosdumay]

> Abstractions usually empower their user, ORMs remove power.

That is an opinion. One could also consider that the fact that you can use programming language to model your database provides a lot of expressive power.