> SQL is itself an abstraction over the "language" of query execution plans. Why do you regard SQL as particularly more fundamental than any other abstraction?
> I don't think it's conceptually right to regard LINQ as a "SQL generator". I think it's better to think of both LINQ and SQL as just different database control languages.
Thats the thing. There is nothing theoretical about this. It is about what is actually closer to the real thing which in this case is the data.
I agree LINQ is far easier to understand and is more productive but those benefit just don't outweigh my performance, safety, and concurrency concerns. Understanding the database along with its native SQL gets you that.
For others the productivity is worth it.
> (It might be the case that behind the scenes LINQ is implemented by generating SQL, but that's an implementation detail. Just like Haskell is implemented by generating C behind the scenes but it's more reasonable to think of Haskell as its own separate programming language than as a "C generator")
> It is about what is actually closer to the real thing which in this case is the data.
Why is SQL closer to the data?
> Understanding the database along with its native SQL gets you that.
My whole point is that SQL is not any more "native" than LINQ. The database takes SQL and computes an execution plan in its own internal representation. This can look totally different from the SQL as the other commentator pointed out. SQL does not in any way correspond to the "native" way the data is stored or how query results are computed.
> Doesn't GHC backend compile directly to assembly?
> My whole point is that SQL is not any more "native" than LINQ. The database takes SQL and computes an execution plan in its own internal representation. This can look totally different from the SQL as the other commentator pointed out. SQL does not in any way correspond to the "native" way the data is stored or how query results are computed.
Yes please point a reference to me to a database that speaks LINQ or how LINQ directly generates to an execution plan (I admit I haven't touched MS SQL Server in some time).
In theory you are right but not in reality. To give another analog you still have to know Javascript to know TypeScript or Coffeescript (or whatever else in vogue) because WASM isn't a reality yet.
SQL is an abstraction over relational algebra. Relational algebra is, for the most part, easy to grasp. You can use it to define a query tree trivially.
Any tool that can map to that query tree has the same level of abstraction as SQL.
Repeat after me, SQL is nothing special. Its semantics are extremely limited. Nothing it does can't really be done by LINQ or a similar DSL that maps to relational algebra operators.
> I don't think it's conceptually right to regard LINQ as a "SQL generator". I think it's better to think of both LINQ and SQL as just different database control languages.
Thats the thing. There is nothing theoretical about this. It is about what is actually closer to the real thing which in this case is the data.
I agree LINQ is far easier to understand and is more productive but those benefit just don't outweigh my performance, safety, and concurrency concerns. Understanding the database along with its native SQL gets you that.
For others the productivity is worth it.
> (It might be the case that behind the scenes LINQ is implemented by generating SQL, but that's an implementation detail. Just like Haskell is implemented by generating C behind the scenes but it's more reasonable to think of Haskell as its own separate programming language than as a "C generator")
Doesn't GHC backend compile directly to assembly?