Quote from
dandl on January 25, 2021, 1:03 pm
There is Microsoft's LINQ to SQL and its "modern" equivalent in Entity Framework which is not string based, and all the many ORMs and database-layer APIs sporting either a new query language or a native query API.
Just a brief note: Linq is brilliant. It's heavily tied into C# generics and lambdas and after a little while you mostly stop writing loops. [In fact almost any loop can be rewritten in Linq, but some are not worth the trouble.] Nobody I know writes C# without it.
Linq query syntax is just plain silly. It adds nothing to the language except pretend SQL. I never use it.
Linq for SQL is the cleverest SQL generator I've ever seen: it's tied into the C# type system and walks a compiled expression tree. I don't like it much, because it looks like Linq but not quite. It has its place, and it does provide a reasonable degree of SQL dialect abstraction.
There is Microsoft's LINQ to SQL and its "modern" equivalent in Entity Framework which is not string based, and all the many ORMs and database-layer APIs sporting either a new query language or a native query API.
Just a brief note: Linq is brilliant. It's heavily tied into C# generics and lambdas and after a little while you mostly stop writing loops. [In fact almost any loop can be rewritten in Linq, but some are not worth the trouble.] Nobody I know writes C# without it.
Linq query syntax is just plain silly. It adds nothing to the language except pretend SQL. I never use it.
Linq for SQL is the cleverest SQL generator I've ever seen: it's tied into the C# type system and walks a compiled expression tree. I don't like it much, because it looks like Linq but not quite. It has its place, and it does provide a reasonable degree of SQL dialect abstraction.
Andl - A New Database Language - andl.org
Quote from
dandl on January 25, 2021, 10:44 pm
I suspect the real problem here is a broader, almost philosophical one: We simply haven't reached that zeitgeist point in our industrial evolution where SQL is seen as a problem.
SQL-wise, we're like the mid 1980's with C, or early 1990's with C++, or late 1970's with COBOL. I.e., it seems perfectly fine, good even.
But in a year or three or ten or twenty, it will all change and there'll be an avalanche of anti-SQL sentiment and our work here will seem uncommonly prescient.
My experience has been that shifts of this kind are driven by seismic shifts in technology, and the willingness of customers to buy shiny new toys. Eg
- Mainframe -> mini -> micro -> handheld -> phone
- Tape -> disk pack -> diskette -> SD/SSD
- Client-server -> mini/VDU -> PC -> browser
- Sequential access -> ISAM -> RDBMS -> ???
So the question is: what kind of data storage/retrieval problem will arise that generates truckloads of cash and for which SQL is not the solution? It's just possible that the RA isn't either.
I suspect the real problem here is a broader, almost philosophical one: We simply haven't reached that zeitgeist point in our industrial evolution where SQL is seen as a problem.
SQL-wise, we're like the mid 1980's with C, or early 1990's with C++, or late 1970's with COBOL. I.e., it seems perfectly fine, good even.
But in a year or three or ten or twenty, it will all change and there'll be an avalanche of anti-SQL sentiment and our work here will seem uncommonly prescient.
My experience has been that shifts of this kind are driven by seismic shifts in technology, and the willingness of customers to buy shiny new toys. Eg
- Mainframe -> mini -> micro -> handheld -> phone
- Tape -> disk pack -> diskette -> SD/SSD
- Client-server -> mini/VDU -> PC -> browser
- Sequential access -> ISAM -> RDBMS -> ???
So the question is: what kind of data storage/retrieval problem will arise that generates truckloads of cash and for which SQL is not the solution? It's just possible that the RA isn't either.
Andl - A New Database Language - andl.org
Quote from
dandl on January 25, 2021, 10:44 pm
I suspect the real problem here is a broader, almost philosophical one: We simply haven't reached that zeitgeist point in our industrial evolution where SQL is seen as a problem.
SQL-wise, we're like the mid 1980's with C, or early 1990's with C++, or late 1970's with COBOL. I.e., it seems perfectly fine, good even.
But in a year or three or ten or twenty, it will all change and there'll be an avalanche of anti-SQL sentiment and our work here will seem uncommonly prescient.
My experience has been that shifts of this kind are driven by seismic shifts in technology, and the willingness of customers to buy shiny new toys. ...
So the question is: what kind of data storage/retrieval problem will arise that generates truckloads of cash and for which SQL is not the solution? It's just possible that the RA isn't either.
They're driven by seismic shifts in capability, too. That's a big part of what makes the shiny new toys appealing -- they give you powers you didn't have before.
That's what we're up against with our relational algebra implementations -- for most of the vast unwashed, they're not different enough from SQL to demonstrate appealing new powers, but are different enough from SQL to demonstrate unappealing incompatibility.
The relational algebra compared to SQL is a bit like, say, Apple's Newton compared to desktop computing and more popular PDAs of the time: Different enough from mainstream computing to be interesting, but not enough new powers to be desirable. It took iPod/iPhone levels of new powers to become desirable.
Quote from
dandl on January 25, 2021, 10:44 pm
I suspect the real problem here is a broader, almost philosophical one: We simply haven't reached that zeitgeist point in our industrial evolution where SQL is seen as a problem.
SQL-wise, we're like the mid 1980's with C, or early 1990's with C++, or late 1970's with COBOL. I.e., it seems perfectly fine, good even.
But in a year or three or ten or twenty, it will all change and there'll be an avalanche of anti-SQL sentiment and our work here will seem uncommonly prescient.
My experience has been that shifts of this kind are driven by seismic shifts in technology, and the willingness of customers to buy shiny new toys. ...
So the question is: what kind of data storage/retrieval problem will arise that generates truckloads of cash and for which SQL is not the solution? It's just possible that the RA isn't either.
They're driven by seismic shifts in capability, too. That's a big part of what makes the shiny new toys appealing -- they give you powers you didn't have before.
That's what we're up against with our relational algebra implementations -- for most of the vast unwashed, they're not different enough from SQL to demonstrate appealing new powers, but are different enough from SQL to demonstrate unappealing incompatibility.
The relational algebra compared to SQL is a bit like, say, Apple's Newton compared to desktop computing and more popular PDAs of the time: Different enough from mainstream computing to be interesting, but not enough new powers to be desirable. It took iPod/iPhone levels of new powers to become desirable.
I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org
