3 ms·

Absolutely! I'm just generally saying that SQL could be more succinct and composable - it's all a combination of project, filter and other primitive operations

by kreetx 3y ago

Absolutely! I'm just generally saying that SQL could be more succinct and composable - it's all a combination of project, filter and other primitive operations from relational algebra. SQL is rather verbose, and the question of whether FROM or SELECT should come first is just paint on the object.

PaulHoule 3y ago
Lately I've been developing a system which represents something like a file tree in SQL tables and using https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-RECURSIVE https://www.postgresql.org/docs/current/queries-with.html#QU... and boy is it an awkward syntax. Circa 2008 I was getting interested in the "semantic web" and wasn't so happy with RDFS and OWL and thought Datalog would be a useful approach and it was an obscure topic then. 10 years later people struggling w/ SQL and other query languages revived it because it seems so much conceptually clean than alternatives. Similarly there is something that looks terribly half-baked about triggers, stored procedures, etc. in SQL and I've long thought something based on production rules could be cleaner but the world just hasn't cared.
- kreetx 3y ago
  I've been on the lookout for new languages as well (though haven't created anything myself - unlike you). I'd say, getting the data (1) and triggers/procedures (2) are totally different domains with regarding to syntax. For select (i.e, 1), I have my ideas, but for (2) I've no clue. For (2), now that I think about it, I would say there are two additional levels of syntax that need to be solved: first, in addition to "getting data" you need also to modify it, so there need be syntax for that part (i.e the UPDATE part of SQL); and second, how to you connect these modifiers to events that happen, this is yet another domain of syntax IMO. (This latter feels like a general purpose programming language already, so maybe build it in to any of them which have great syntax already?)

by kreetx 3y ago

PaulHoule 3y ago

Lately I've been developing a system which represents something like a file tree in SQL tables and using https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-RECURSIVE https://www.postgresql.org/docs/current/queries-with.html#QU... and boy is it an awkward syntax. Circa 2008 I was getting interested in the "semantic web" and wasn't so happy with RDFS and OWL and thought Datalog would be a useful approach and it was an obscure topic then. 10 years later people struggling w/ SQL and other query languages revived it because it seems so much conceptually clean than alternatives. Similarly there is something that looks terribly half-baked about triggers, stored procedures, etc. in SQL and I've long thought something based on production rules could be cleaner but the world just hasn't cared.

kreetx 3y ago
I've been on the lookout for new languages as well (though haven't created anything myself - unlike you). I'd say, getting the data (1) and triggers/procedures (2) are totally different domains with regarding to syntax. For select (i.e, 1), I have my ideas, but for (2) I've no clue. For (2), now that I think about it, I would say there are two additional levels of syntax that need to be solved: first, in addition to "getting data" you need also to modify it, so there need be syntax for that part (i.e the UPDATE part of SQL); and second, how to you connect these modifiers to events that happen, this is yet another domain of syntax IMO. (This latter feels like a general purpose programming language already, so maybe build it in to any of them which have great syntax already?)