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?
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 nestedwhileloops are more than likely a code smell. I agree, everything does get boiled down tojmpinstructions at the bare metal. However, I think that the big distinction with Dijkstra's statement is that we should strive to removegotoin 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