4 ms·

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

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

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