Comment by fckgnad | Hacker News Reader

Comment by fckgnad | Hacker News Reader

Parent Full thread

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)

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.

>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.

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

Reply on news.ycombinator.com