Hacker News Reader

Comment by sirsinsalot | Hacker News Reader

> if you want to create a tree or a graph for graph algorithms like bfs or dfs on top of a non graph database then ORMs are literally the main abstraction to use. That's it. This is rare

You said it yourself, if you want to store a graph (in memory object instancss referring to each other by reference) in a non-graph database (say postgres or mysql) then an ORM is the thing to use.

This is literally what everyone uses them for. You defined their use, and that's what we're all doing with them and finding immense value from them doing it simply.

It isn't rare. It is literally the common case in every web app everywhere. There are more examples of an ORM being good and providing value, in the real world than not.

I'll just carry on using them and finding them valuable, and in the rare corner case their limit is exceeded then take the harder or more complex option.

Best tool for the job.

View on HN

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