5 ms·

ORMs are bad because it's a high level abstraction on top of a high level abstraction. SQL is already high level, so it's pointless to build on top of it. It al

ORMs are bad because it's a high level abstraction on top of a high level abstraction. SQL is already high level, so it's pointless to build on top of it. It also makes things much much more harder as SQL is a leaky abstraction and all leaks need to be passed through from one high level abstraction all the way up another one. Let's say I wanted to build an abstraction on top of ORMs. You would think I'm crazy. Why? Pause here for a bit. Your rationale here... is exactly why you don't want to build an abstraction over SQL. Anyway. The author does have a somewhat valid point about the auto joining of foreign key relationships on a table. But this is only one missing feature. Creating a whole new high level dsl on top of another high level dsl just for this is over engineering. The real abstraction needed here is some sort of extension to SQL. Either extend the language itself in the standards, or the implementation or typescript style via transpilation. The only other valid reasoning behind ORMs is just cosmetic such that you don't have to have to deal with SQL primitives as strings inside another language.

sirsinsalot 4y ago
> SQL is already high level, so it's pointless to build on top of it. I'm not sure that's a truism at all
- fckgnad 4y ago
  It's a generality that's generally true. It's also common sense. For the same reason why Translating python to ruby is generally and obviously pointless. The main thing that makes ORMs alluring is that people don't like to mess with a language in a language. Dealing with strings is inelegant. Seeing why the orm is worse then string manipulation requires a 4 dimensional perspective shift that's really hard for people to comprehend.
  - sirsinsalot 4y ago
    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.
    - fckgnad 4y ago
      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.
      - sirsinsalot 4y ago
        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.
        fckgnad 4y ago
        >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?
sam_lowry_ 4y ago
>don't have to have to deal with SQL primitives I believe the root cause is that many programmers do not like string manipulations inside their very own programming "language", be it Spring Boot or Nodejs /s
- fckgnad 4y ago
  I completely agree. I think it's ocd thing. Programmers turn to ORMs because they appear elegant as it gets rid of string manipulation. You need a higher level perspective shift to realize that the orm is actually the uglier abstraction then just using plain strings.
  - arrow7000 4y ago
    It's also because having your SQL just be a plain string means you lose type safety and have to do a bunch of type casting on the results of your query, which may or may not be faithful to the DB's actual model
    - fckgnad 4y ago
      If you want static checks it needs to be done separately from the main language. What I find is that a good ide or editor is capable of doing this for a string if you tell it what that string is. Static checks are not a reason to create a whole new abstraction over a language. As I said it's a sign that new features are needed as an extension. In terms of type safety for SQL I find certain ides already cover most of this so even a typescript style extension on top of SQL is not needed.
randomdata 4y ago
The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. Unless your entire application is modelled as relations, there is no avoiding this transformation step, be it whether you use a toolkit to help you or slog it by hand. SQL doesn't help you here. SQL is just a query language that is designed around the relational model (more or less). The same relational model that your application isn't (likely) designed around. Thus, again, you need object relation mapping to provide the conversion between SQL's model and your application's model. Some ORM toolkits also bundle query builders. The query builder may be what you find unnecessary, but I'm not sure the existence of query builders is crazy. These query builders essentially become another programming language that compiles to SQL. The idea of a programming language compiling to another programming language isn't crazy at all. We do it all the time with great success. Although there is debate as to whether or not it is due to SQL/RDBMSes not being purely relational or if it is more fundamental, what is agreed upon is that there is an object relation impedance mismatch. This makes it a hard problem to solve and many ORM toolkits only provide half solutions, and this is where a lot of friction comes into play.
- fckgnad 4y ago
  >The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. I am saying this transformation step is pointless. It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. You don't need the object abstraction. SQL is already a high level abstraction. Tables and foreign keys already cover everything you need including the relations. You are converting tables to objects. One high level abstraction to another. It's like translating English to Chinese to explain something to someone who is already bilingual. Here's another way to put it: The models already exist in the database. Why build a repetitive model in the application language? It's a cosmetic thing because people don't want to deal with string manipulation. Overall most of your logic and abstractions lives in the strings you pass to the database. There should be minimal structure and logic for database queries outside of strings in the application code.
  - randomdata 4y ago

sirsinsalot 4y ago

> SQL is already high level, so it's pointless to build on top of it. I'm not sure that's a truism at all

fckgnad 4y ago
It's a generality that's generally true. It's also common sense. For the same reason why Translating python to ruby is generally and obviously pointless. The main thing that makes ORMs alluring is that people don't like to mess with a language in a language. Dealing with strings is inelegant. Seeing why the orm is worse then string manipulation requires a 4 dimensional perspective shift that's really hard for people to comprehend.
- sirsinsalot 4y ago
  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.
  - fckgnad 4y ago
    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.
    - sirsinsalot 4y ago
      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.
      - fckgnad 4y ago
        >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?

sam_lowry_ 4y ago

>don't have to have to deal with SQL primitives I believe the root cause is that many programmers do not like string manipulations inside their very own programming "language", be it Spring Boot or Nodejs /s

fckgnad 4y ago
I completely agree. I think it's ocd thing. Programmers turn to ORMs because they appear elegant as it gets rid of string manipulation. You need a higher level perspective shift to realize that the orm is actually the uglier abstraction then just using plain strings.
- arrow7000 4y ago
  It's also because having your SQL just be a plain string means you lose type safety and have to do a bunch of type casting on the results of your query, which may or may not be faithful to the DB's actual model
  - fckgnad 4y ago
    If you want static checks it needs to be done separately from the main language. What I find is that a good ide or editor is capable of doing this for a string if you tell it what that string is. Static checks are not a reason to create a whole new abstraction over a language. As I said it's a sign that new features are needed as an extension. In terms of type safety for SQL I find certain ides already cover most of this so even a typescript style extension on top of SQL is not needed.

randomdata 4y ago

The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. Unless your entire application is modelled as relations, there is no avoiding this transformation step, be it whether you use a toolkit to help you or slog it by hand. SQL doesn't help you here. SQL is just a query language that is designed around the relational model (more or less). The same relational model that your application isn't (likely) designed around. Thus, again, you need object relation mapping to provide the conversion between SQL's model and your application's model. Some ORM toolkits also bundle query builders. The query builder may be what you find unnecessary, but I'm not sure the existence of query builders is crazy. These query builders essentially become another programming language that compiles to SQL. The idea of a programming language compiling to another programming language isn't crazy at all. We do it all the time with great success. Although there is debate as to whether or not it is due to SQL/RDBMSes not being purely relational or if it is more fundamental, what is agreed upon is that there is an object relation impedance mismatch. This makes it a hard problem to solve and many ORM toolkits only provide half solutions, and this is where a lot of friction comes into play.

fckgnad 4y ago
>The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. I am saying this transformation step is pointless. It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. You don't need the object abstraction. SQL is already a high level abstraction. Tables and foreign keys already cover everything you need including the relations. You are converting tables to objects. One high level abstraction to another. It's like translating English to Chinese to explain something to someone who is already bilingual. Here's another way to put it: The models already exist in the database. Why build a repetitive model in the application language? It's a cosmetic thing because people don't want to deal with string manipulation. Overall most of your logic and abstractions lives in the strings you pass to the database. There should be minimal structure and logic for database queries outside of strings in the application code.
- randomdata 4y ago