4 ms·

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

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?
    - sirsinsalot 4y ago
      > 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.

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?
  - sirsinsalot 4y ago
    > 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.