Hacker News Reader

Comment by sirsinsalot | Hacker News Reader

Is TypeScript bad because it is built on a high level abstraction? What about Sass. Or perhaps the HTTP request handler abstractions built on the (already high level) HTTP protocol abstractions?

Or any high level language built on a highly abstracted VM? Are they bad just because of their abstraction degree?

Highness of abstractions is relative not absolute.

What about a UI library? Or image manipulation library? Must you mutate a bitmap yourself?

I don't think it always holds true, but rather many poor tools happen to be leaky abstractions or compounded leaky abstractions.

I don't think the "level" is important except where any lower level is a bad foundation.

They're not all bad foundations.

View on HN

I stated in my first post that the proper abstraction is an extension to SQL. It is ok to extend a language to cover missing features or correct mistakes.

Typescript and sass are extensions, that's why they are good. ORMs are not extensions.

Before the advent of advanced natural language processing like chatGPT, SQL was literally one of the highest level of language abstractions we can arrive at. It's declarative and English like.

Thus, given that SQL is generally at the highest level... any abstraction you would've built on top SQL would inevitably and in general not be higher. These abstractions are movements in progress that are horizontal in nature and therefore relatively pointless.

The point of most abstractions is to provide a higher level interface. An orm does not do this. Instead an orm is a shift in philosophy that declares the SQL philosophy to be incorrect.

I don't completely disagree with that philosophy. But the proper way to implement your philosophy is to write a database; not a transpiler that transpiles your philosophy onto a technology with a different philosophy.

I don't think it is that black and white. An ORM has utility for many use cases.

I think too many people try and discuss tools based on things that aren't relevant or are idealistic or that remove the nuance from the argument.

Does transpiling make for a bad tool? Depends on the use case. Does mapping from tables to objects make a bad tool, again depends on the use case.

I think any discussion of tools without a clearly scoped use case is next to useless.

>I think too many people try and discuss tools based on things that aren't relevant or are idealistic or that remove the nuance from the argument.

Some people think the universe is just apple and oranges. Everything is a tool that can be used somewhere nothing is truly good or bad. Well how about that? On the entire earth there isn't a technology that is absolutely great or raw shit and anyone who has such an opinion lacks nuance or is too idealistic.

No. To over-rely on nuance is to say nothing is black and nothing is white and everything is nuanced even when the nuance is inconsequential. This is wrong. Generalities and essential truths exist. For example, punching yourself in the face is generally bad, but if you talk about nuance and context then if you had a poisonous bug on your face, then punching yourself to save your own life is a good thing. But despite this the generality remains true.

The nuance for ORMs is only this: 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, because usually you have other databases other then relational that are better for this. But if you don't have the resources to load an entirely new type of database into production then ORMs are one way to perform graph algorithms on an existing SQL database.

For this instance the situation is clear, the nuance is negligible. ORMs are bad for most cases the same way eating poison is bad for you in most cases. If you want to talk about the nuance of when eating poison is sometimes good for you, be my guest. But the generality remains true.

>I think any discussion of tools without a clearly scoped use case is next to useless.

Agreed. Let's scope it to the all practical use cases seen in the wild. My argument is for the vast majority of use cases ORMs provide little benefit other then cosmetic.

This whole thing about scope is quite pointless imo. Because obviously the above scope I described basically what I'm referring to. You know it. Why do I need to spell this out specifically or be useless? Shouldn't the implication of scope be derived automatically from the discussion via usage of common sense?

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

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