3 ms·
> The argument against ORMs aren't that they are a leaky abstraction (although they most definitely are). I'm not using an "OO" language these days, so I don't
by ken 7y ago
> The argument against ORMs aren't that they are a leaky abstraction (although they most definitely are).
I'm not using an "OO" language these days, so I don't really have a horse in this race, but: isn't the problem you mention here completely explained by the leakiness?
Replace "ORM" with "compiler" and "SQL" with "assembly language", and this is exactly the argument I heard back in the 1980's about why not to use a compiler, or in the 1990's about why not to use a GC. Nobody I know is writing assembly language at all any more. It sucks at composition, so even though it's better at many tactical micro-optimizations, we've improved compilers to the point that we can use them all the time, because it helps productivity massively.
> and if you need something more complex, compose it from simpler ones
Composition is the killer feature in all of software building, and the fatal flaw of assembly, and SQL. We use higher-level languages for their composition abilities, even when they are less efficient. When their inefficiencies make them unusable, we make them smarter, even when it means designing new languages with 100+ keywords (ugh).
If the major complaint against ORMs is that they aren't good enough to make the value worth it in all cases, well, yeah, I've seen that phase of literally every other technology I'm using today. This, too, will pass.
- mntmoss 7y agoComparing SQL - a 4GL - to assembly language seems disingenuous at best, to the point where the Blub paradox applies. (And lo and behold, just four days ago you compared SQL to Lisp on the basis of incompatible implementation!) Unlike assembly, which is famously redundant, SQL doesn't have much to abstract away, and the majority of counterexamples are covered by macros. The things that it really can't abstract are the implementation details that you want to care about when you optimize. Some parts could be a little less clunky, in the same way that the C language could be a little less clunky, but the successful track record of SQL over decades speaks volumes: it's not the stuff going on inside the database causing people the most grief, it's the programming goop that gets attached to it.
- srean 7y agoHe does have a point about composability though. Wonder how, things would have turned out had prolog become the default query language.
- asdfman123 7y agoThe difference is that in my whole programming career I've never had a problem with a compiler. I have spent so many hours battling Entity Framework when writing the exact query I need is absolutely trivial. It's a rabbit hole, and it can blow up deadlines unpredictably. Next time I start a new project I'm just using straight Dapper.