SQL is already a very high level API that compiles to low level algorithms? Why put another very high level API on top of that?
To top it off SQL is a leaky abstraction by nature. Two high level SQL queries with equivalent results can both compile into algorithms with COMPLETELY different performance profiles. You have to manipulate the SQL query to generate the correct performance profile. This means understanding things below the SQL abstraction.
You put a ORM or any new abstraction on top of that guess what? That abstraction must compile into hacked SQL. You have to be able to manipulate the ORM such that it generates the correct SQL such that the correct SQL generates the algorithm with the correct performance profile. The leak from the sql abstraction must propogate into the ORM layer which in itself must be a leaky abstraction. It's like dealing with a leaky pipe embedded within another leaky pipe.
Optimizing SQL is already a domain knowledge thing. Now you have to use new tricks to optimize the abstraction on top of it. Two Leaky abstractions on top of each other and both very high level is a bit of a head scratcher.
Why do people even make these abstractions that only make life harder? I think it's an illusion. It's to satisfy an OCD thing but people don't realize the OCD is an illusion. People want to deal with a single language, not have strings of another language living in the code. For example, SQL strings are seemingly kind of ugly in something like GO code.
Databases are the classic bottleneck of web development in terms of speed. Optimization is a very important part of writing SQL queries as a result. Having orms and other high level abstractions on top of this area is much much more harmful then it otherwise would be if databases did not exist in this bottle-necked area of web development.
In actuality it's also questionable whether or not a leaky abstraction in the first place was the right design decision. Is SQL the right abstraction for database queries? Or should we design another high level API that has a more 1 to 1 correspondence with optimization as in a High level API that's not leaky, like What Rust is to systems programming.
SQL is already a very high level API that compiles to low level algorithms? Why put another very high level API on top of that?
To top it off SQL is a leaky abstraction by nature. Two high level SQL queries with equivalent results can both compile into algorithms with COMPLETELY different performance profiles. You have to manipulate the SQL query to generate the correct performance profile. This means understanding things below the SQL abstraction.
You put a ORM or any new abstraction on top of that guess what? That abstraction must compile into hacked SQL. You have to be able to manipulate the ORM such that it generates the correct SQL such that the correct SQL generates the algorithm with the correct performance profile. The leak from the sql abstraction must propogate into the ORM layer which in itself must be a leaky abstraction. It's like dealing with a leaky pipe embedded within another leaky pipe.
Optimizing SQL is already a domain knowledge thing. Now you have to use new tricks to optimize the abstraction on top of it. Two Leaky abstractions on top of each other and both very high level is a bit of a head scratcher.
Why do people even make these abstractions that only make life harder? I think it's an illusion. It's to satisfy an OCD thing but people don't realize the OCD is an illusion. People want to deal with a single language, not have strings of another language living in the code. For example, SQL strings are seemingly kind of ugly in something like GO code.
Databases are the classic bottleneck of web development in terms of speed. Optimization is a very important part of writing SQL queries as a result. Having orms and other high level abstractions on top of this area is much much more harmful then it otherwise would be if databases did not exist in this bottle-necked area of web development.
In actuality it's also questionable whether or not a leaky abstraction in the first place was the right design decision. Is SQL the right abstraction for database queries? Or should we design another high level API that has a more 1 to 1 correspondence with optimization as in a High level API that's not leaky, like What Rust is to systems programming.