3 ms·

But that doesn't contradict my point. The mathematical basis matters, sure, but the language on top of it (exactly because it derives from the math anyway) is m

But that doesn't contradict my point. The mathematical basis matters, sure, but the language on top of it (exactly because it derives from the math anyway) is mostly irrelevant. I don't really care if I have to write SELECT or \forall or σ as long as they all have the same meaning. But I'd prefer to use SELECT because I already spent time learning how to work this way. SQL as a language is fine. There is no real need to reinvent SQL unless you're going to reinvent the math behind it too.

throwaway_pdp09 6y ago
2 points then; 1. Do you know SQL currently? Because your previous comments implied you don't 2. SQL is a bad implementation of the underlying relational model. And it's just bad in other ways. For one, it's bloody wordy: select * from people but as SQL is an expression language, why not? people From an answer of mine a few days ago (slightly modified here) to pick out differences: ( select * from t1 except select * from t2 ) union ( select * from t2 except select * from t1 ) I'd prefer to write that crap as (t1 \ t2) + (t2 \ t1) or similar. If you write a lot of SQL, that matters. SQL aggregates don't nest easily. Transactions are screwed up (https://news.ycombinator.com/item?id=23569513 https://news.ycombinator.com/item?id=23569513). SQL is poorly composable (https://news.ycombinator.com/item?id=23550420#23561301 https://news.ycombinator.com/item?id=23550420#23561301). For better or worse it has nulls therefore tristate logic. This causes errors! And more. BTW. transactions don't work in the way you might think, atomically. Which is why MS added https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xact-abort-transact-sql?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xa... and I'm sure Pgres has similar. From the link: "When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing" That peculiarity is from the standard BTW. SQL is problematic. It could have been much better.

throwaway_pdp09 6y ago

2 points then; 1. Do you know SQL currently? Because your previous comments implied you don't 2. SQL is a bad implementation of the underlying relational model. And it's just bad in other ways. For one, it's bloody wordy: select * from people but as SQL is an expression language, why not? people From an answer of mine a few days ago (slightly modified here) to pick out differences: ( select * from t1 except select * from t2 ) union ( select * from t2 except select * from t1 ) I'd prefer to write that crap as (t1 \ t2) + (t2 \ t1) or similar. If you write a lot of SQL, that matters. SQL aggregates don't nest easily. Transactions are screwed up (https://news.ycombinator.com/item?id=23569513 https://news.ycombinator.com/item?id=23569513). SQL is poorly composable (https://news.ycombinator.com/item?id=23550420#23561301 https://news.ycombinator.com/item?id=23550420#23561301). For better or worse it has nulls therefore tristate logic. This causes errors! And more. BTW. transactions don't work in the way you might think, atomically. Which is why MS added https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xact-abort-transact-sql?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xa... and I'm sure Pgres has similar. From the link: "When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing" That peculiarity is from the standard BTW. SQL is problematic. It could have been much better.