3 ms·

Wow, kunley, I just had a flashback to 15 years ago when Object DB zealots were making these same kind of dogmatic go-back-to-set-theory arguments. Yes! We get

Wow, kunley, I just had a flashback to 15 years ago when Object DB zealots were making these same kind of dogmatic go-back-to-set-theory arguments. Yes! We get it! We got it years ago: ORMs are a compromise over an irreducible set-theoretical problem. I got it in CS class and I get it now. You can't square the circle -- no one is claiming to have squared the circle. But for 90% of the cases, it turns out that really experienced developers use and leverage ORMs to boost productivity and eliminate code duplication. It happens every day. It's not habits and tools, it's from careful consideration of the results of what happens in practice. Good Baconian Science should teach us to go out into the world and observe and report. And what we've learned is that neither side of the Object/Relational tension really ever fully wins out, and what works is experienced devs using the right tool at the right time. We code in the real world, get burned by bad practice and adjust. That's why ORMs have survived, because good devs have found ways to used them as effective bandaids on difficult problems. We don't code in a classroom and I couldn't care less whether my code violates anybody's CS or Set Theory dogma. I have features to ship.

kunley 15y ago
Well, just assume that I'm also speaking from experience of delivering complicated applications to production and I'm tired of how ORMs become a pain in the long term: - they create a dangerous illusion of an leaky abstraction which leaks very quickly - they require programmers to learn 2 things anyway - they initially speed up the coding, but later slow it down, esp. when you have to tune stuff (how many times you peeked generated SQLs only in order to feed them to EXPLAIN ANALYZE... ?) - they can promote bad habits, code which takes your engine to a crawl - they hinder debugging, esp. tracking performance problems, often effectively putting a problem under the carpet to be discovered by admins There's also a funny thing: most of the world seems to happily use active record (as a pattern), although when you go deep into it it occurs far inferior to data mapper (as a pattern). That also demonstrates that many people are using habits, not engineering, and stick to what's used around instead of making some investigation on the topic. This is not bad per se; but when it comes to discussing problems, such people are not in the position to argue, precisely because they haven't done their homework. So, the problems above are caused by the mismatch which one can expect from the theory. You've got what you paid for. I guess we all could learn most from the history of relational databases or just try to remember what relational databases really are and what other examples of this technology are around. For example Prolog is relational (apart from logic engine). If one does something in it then it becomes more clear how much it "fits" objects or not.

kunley 15y ago

Well, just assume that I'm also speaking from experience of delivering complicated applications to production and I'm tired of how ORMs become a pain in the long term: - they create a dangerous illusion of an leaky abstraction which leaks very quickly - they require programmers to learn 2 things anyway - they initially speed up the coding, but later slow it down, esp. when you have to tune stuff (how many times you peeked generated SQLs only in order to feed them to EXPLAIN ANALYZE... ?) - they can promote bad habits, code which takes your engine to a crawl - they hinder debugging, esp. tracking performance problems, often effectively putting a problem under the carpet to be discovered by admins There's also a funny thing: most of the world seems to happily use active record (as a pattern), although when you go deep into it it occurs far inferior to data mapper (as a pattern). That also demonstrates that many people are using habits, not engineering, and stick to what's used around instead of making some investigation on the topic. This is not bad per se; but when it comes to discussing problems, such people are not in the position to argue, precisely because they haven't done their homework. So, the problems above are caused by the mismatch which one can expect from the theory. You've got what you paid for. I guess we all could learn most from the history of relational databases or just try to remember what relational databases really are and what other examples of this technology are around. For example Prolog is relational (apart from logic engine). If one does something in it then it becomes more clear how much it "fits" objects or not.