4 ms·

Some tools are garbage. But according to the logic you present here such a universe with garbage tools doesn't exist, even a piece of shit has some sort of use

Some tools are garbage. But according to the logic you present here such a universe with garbage tools doesn't exist, even a piece of shit has some sort of use in programming. "best tool for the job" is a niave and illusory statement. There is merit in declaring something bad at everything or good at everything. Anyway. Dfs or bfs queries are extremely rare in SQL and much of web dev too and they still can be done without an orm and all within database code. The amount of times you see a recursive query is the amount of times an orm would've made that slightly easier. Not worth an entire abstraction for such a rare and impractical feature. If what you say is true and it's not rare, then I offer you the concept of a graph database that's designed for graph algorithms. That is the "best tool for the job" rendering the orm not the best at anything. (I edited this from "your logic" to the "logic you present" not making any remark on your intelligence here hope it doesn't come off that way)

sirsinsalot 4y ago
Even if your technical point is true, "right tool for the job" goes beyond the rigidity of the technical. I use an ORM because it is cheap, easy, quick, uses a known quantity database which is readily available and deployable and allows me to solve my business case with relatively low complexity exposure and risk. Best tool for the job. Best, as subjectively defined by me, for my needs as I see them in this un-black-and-white world. Idealism is the enemy of done and I care about done (with proper engineering constraints) much more than "right". I care even less about trying to define a vague approximation of "right" when there's things to get "done" and the ORM I use is tried and tested to get things done. That's my use case. Done. That's my tool for that use case. Everything else is balancing debt, risk and entropy. Right doesn't factor into it for me. It is quite liberating.
- fckgnad 4y ago
  >Idealism is the enemy of done and I care about done Nobody is talking about idealism. It's all practical. What my claim is this: You are wrong. In both cases you can get things "done" but you'd get things done faster and more easily without the ORM, you just don't know it. That's the claim I am making. Your claim is that my reasoning is based on theoretical ideals. But I never stated such a thing, so I am stating it now: The basis of my logic rests on practicality NOT idealism. The funny thing is, SQL as strings is viewed as more "practical" given how inelegant and "un-ideal" string manipulation is. The ORM is more of the misguided attempt to reach an idealism through abstraction.
  - turtleyacht 4y ago
    Do you have any patterns for this? Not OOP Design Patterns necessarily, but your preferred workflow patterns for managing complexity. For example (just examples!): * Apps (usually) only use (materialized?) view tables * Deployments are checked in as migrations * Aggressively leverage db features like caching or other specific performance features (not just indexing) * GraphQL to firewall backend devs from rapidly changing frontend "widget" requests

sirsinsalot 4y ago

Even if your technical point is true, "right tool for the job" goes beyond the rigidity of the technical. I use an ORM because it is cheap, easy, quick, uses a known quantity database which is readily available and deployable and allows me to solve my business case with relatively low complexity exposure and risk. Best tool for the job. Best, as subjectively defined by me, for my needs as I see them in this un-black-and-white world. Idealism is the enemy of done and I care about done (with proper engineering constraints) much more than "right". I care even less about trying to define a vague approximation of "right" when there's things to get "done" and the ORM I use is tried and tested to get things done. That's my use case. Done. That's my tool for that use case. Everything else is balancing debt, risk and entropy. Right doesn't factor into it for me. It is quite liberating.

fckgnad 4y ago
>Idealism is the enemy of done and I care about done Nobody is talking about idealism. It's all practical. What my claim is this: You are wrong. In both cases you can get things "done" but you'd get things done faster and more easily without the ORM, you just don't know it. That's the claim I am making. Your claim is that my reasoning is based on theoretical ideals. But I never stated such a thing, so I am stating it now: The basis of my logic rests on practicality NOT idealism. The funny thing is, SQL as strings is viewed as more "practical" given how inelegant and "un-ideal" string manipulation is. The ORM is more of the misguided attempt to reach an idealism through abstraction.
- turtleyacht 4y ago
  Do you have any patterns for this? Not OOP Design Patterns necessarily, but your preferred workflow patterns for managing complexity. For example (just examples!): * Apps (usually) only use (materialized?) view tables * Deployments are checked in as migrations * Aggressively leverage db features like caching or other specific performance features (not just indexing) * GraphQL to firewall backend devs from rapidly changing frontend "widget" requests