Object-relational mapping, aka the Vietnam of computer science.
Honestly, I don't think even goto is an excommunicable offense. It's a very simple, very powerful tool that's very easy to do terrible things with, and it's almost always better to use other control structures to manage execution flow in more readable terms, but there are exceptions to everything. Notably the case of breaking out of nested while loops is only easily accomplished with goto. And of course all loops reduce down to jmp statements in assembly so we're technically all guilty anyway.
Thanks for that article link.
I am so excited to read that you have no idea.
I'll admit that at first glance, I thought that the linked article was going to be hyperbolic. However, the parallels that it drew were quite interesting and it was a really insightful read. It definitely helped me solidify some thoughts I'd had about ORMs, specifically the issue of schema ownership. Thank you for the link!
To your other point about the utility of goto, I'd argue that multiple nested while loops are more than likely a code smell. I agree, everything does get boiled down to jmp instructions at the bare metal. However, I think that the big distinction with Dijkstra's statement is that we should strive to remove goto in high-level languages. They definitely have a place in low-level languages.
Finally, while I can pretty much agree with your stance on ORMs, I'm curious about alternatives to ORMs. Do you have some suggestions? I'm always interested in learning more. Do you think that RDMS is more of the issue with ORMs and we should use more of a document store à la MongoDB, a graph DB such as Neo4j? And do you share similar feelings about GraphQL as ORMs?
Thanks again for the comment and the article!
We had a thread about O/RMs and other data access patterns fairly recently so I'll just point you there rather than repeat myself :) But I love working with relational databases; they're the Swiss army knife of data storage solutions, where every other form of database I've encountered has been a specialized tool for working with specific architectural patterns: document databases for hierarchical information with few to no interconnections, BigTable derivatives for accumulation of flat records, and so on. They do well for the situation they're designed to operate in, and very poorly anywhere else.
I haven't explored GraphQL much at all. I like SQL and can do basically anything I need to with that, so until someone creates a database that uses GraphQL as a native query language instead (it's probably not too far off), I don't have a reason to use it. But it seems helpful for others, and doesn't have the fundamental impedance mismatch that makes O/RMs a problem.
I've played a bit with GraphQL and Django's ORM (meh) today and I'm quite sure everything is going to explode when queries become really complicated :D
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.