6 ms·

I don't want to come off as too overconfident, but would be very hard pressed to see the value of this. At face value, I shudder at the syntax. Example from t

I don't want to come off as too overconfident, but would be very hard pressed to see the value of this. At face value, I shudder at the syntax. Example from their tutorial: EmployeeName(name:) :- Employee(name:); Engineer(name:) :- Employee(name:, role: "Engineer"); EngineersAndProductManagers(name:) :- Employee(name:, role:), role == "Engineer" || role == "Product Manager"; vs. the equivalent SQL: SELECT Employee.name AS name FROM t_0_Employee AS Employee WHERE (Employee.role = "Engineer" OR Employee.role = "Product Manager"); SQL is much more concise, extremely easy to follow. No weird OOP-style class instantiation for something as simple as just getting the name. As already noted in the 2021 discussion, what's actually the killer though is adoption and, three years later, ecosystem. SQL for analytics has come an extremely long way with the ecosystem that was ignited by dbt. There is so much better tooling today when it comes to testing, modelling, running in memory with tools like DuckDB or Ibis, Apache Iceberg. There is value to abstracting on top of SQL, but it does very much seem to me like this is not it.

Tomte 2y ago
The syntax is Prolog-like, so people in the field are familiar with it.
- thenaturalist 2y ago
  Which field would that be? I.e. I understand now that it's seemingly about more than simple querying, so me coming very much from an analytics/ data crunching background am wondering what a use case would look like where this is arguably superior to SQL.
  - tannhaeuser 2y ago
    > Which field would that be? Database theory papers and books have used Prolog/Datalog-like syntax throughout the years, such as those by Serge Abiteboul, just to give a single example of a researcher and prolific author over the decades.
  - evgskv 2y ago
    In my opinion any analytical query is easier to read in logic language than in SQL. But it's most obvious for recrusive querries. E.g. distance in graph defined by predicate (aka table) G written in Logica looke like: D(a, b) Min= 1 :- G(a, b); # Connected by an edge => distance 1. D(a, c) Min= D(a, b) + D(b, c); # Triangle inequality. It will be much harder to read with SQL CTE. It can also computed over weighted graphs, which is impossible or extremely hard with SQL. In practice you rarely need recursive querries, so gap between Logica and SQL isn't as large as it is here, but Logica is easier to read (in my opinion) for similar reasons.
aseipp 2y ago
Logica is in the Datalog/Prolog/Logic family of programming languages. It's very familiar to anyone who knows how to read it. None of this has anything to do with OOP at all and you will heavily mislead yourself if you try to map any of that thinking onto it. (Beyond that, and not specific to Logica or SQL in any way -- comparing two 3-line programs to draw conclusions is effectively meaningless. You have to actually write programs bigger than that to see the whole picture.) Datalog is not really a query language, actually. But it is relational, like SQL, so it lets you express relations between "facts" (the rows) inside tables. But it is more general, because it also lets you express relations between tables themselves (e.g. this "table" is built from the relationship between two smaller tables), and it does so without requiring extra special case semantics like VIEWs. Because of this, it's easy to write small fragments of Datalog programs, and then stick it together with other fragments, without a lot of planning ahead of time, meaning as a language it is very compositional. This is one of the primary reasons why many people are interested in it as a SQL alternative; aside from your typical weird SQL quirks that are avoided with better language design (which are annoying, but not really the big picture.)
- thenaturalist 2y ago
  > but it is more general, because it also lets you express relations between tables themselves (e.g. this "table" is built from the relationship between two smaller tables), and it does so without requiring extra special case semantics like VIEWs. If I understand you correctly, you can easily get the same with ephemeral models in dbt or CTEs generally? > Because of this, it's easy to write small fragments of Datalog programs, and then stick it together with other fragments, without a lot of planning ahead of time, meaning as a language it is very compositional. This can be a benefit in some cases, I guess, but how can you guarantee correctness with flexibility involved? With SQL, I get either table or column level lineage with all modern tools, can audit each upstream output before going into a downstream input. In dbt I have macros which I can reuse everywhere. It's very compositional while at the same time perfectly documented and testable at runtime. Could you share a more specific example or scenario where you have seen Datalog/ Logica outperform a modern SQL setup? Generally curious. I am not at all familiar with the Logica/Datalog/Prolog world.
jyounker 2y ago
> No weird OOP-style class instantiation for something as simple as just getting the name. I understand the desire to no waste your time, but I think you're missing the big idea. Those statements define logical relations. There's nothing related to classes or OOP. Using those building blocks you can do everything that you can with SQL. No need for having clauses. No need for group by clauses. No need for subquery clauses. No need for special join syntax. Just what you see above. And you can keep going with it. SQL quickly runs into the limitations of the language. Using the syntax above (which is basically Prolog) you can construct arbitrarily large software systems which are still understandable. If you're really interested in improving as a developer, then I suggest that spend a day or two playing with a logic programming system of some sort. It's a completely different way of thinking about programming, and it will give you mental tools that you will never pick up any other way.
- thenaturalist 2y ago
  Really appreciate your response and perspective! Goes on the holidays list.
snthpy 2y ago
Have a look at PRQL [1] for analytical queries. That's exactly what it's designed for. Disclaimer: I'm a contributor. That said. I like Logica and Datalog. For me the main use case is "recursive" queries as they are simpler to express that way. PRQL has made some progress there with the loop operator but it could still be better. If you have any ideas for improvement, please reach out! 1: https://prql-lang.org/ https://prql-lang.org/

Tomte 2y ago

The syntax is Prolog-like, so people in the field are familiar with it.

thenaturalist 2y ago
Which field would that be? I.e. I understand now that it's seemingly about more than simple querying, so me coming very much from an analytics/ data crunching background am wondering what a use case would look like where this is arguably superior to SQL.
- tannhaeuser 2y ago
  > Which field would that be? Database theory papers and books have used Prolog/Datalog-like syntax throughout the years, such as those by Serge Abiteboul, just to give a single example of a researcher and prolific author over the decades.
- evgskv 2y ago
  In my opinion any analytical query is easier to read in logic language than in SQL. But it's most obvious for recrusive querries. E.g. distance in graph defined by predicate (aka table) G written in Logica looke like: D(a, b) Min= 1 :- G(a, b); # Connected by an edge => distance 1. D(a, c) Min= D(a, b) + D(b, c); # Triangle inequality. It will be much harder to read with SQL CTE. It can also computed over weighted graphs, which is impossible or extremely hard with SQL. In practice you rarely need recursive querries, so gap between Logica and SQL isn't as large as it is here, but Logica is easier to read (in my opinion) for similar reasons.

aseipp 2y ago

Logica is in the Datalog/Prolog/Logic family of programming languages. It's very familiar to anyone who knows how to read it. None of this has anything to do with OOP at all and you will heavily mislead yourself if you try to map any of that thinking onto it. (Beyond that, and not specific to Logica or SQL in any way -- comparing two 3-line programs to draw conclusions is effectively meaningless. You have to actually write programs bigger than that to see the whole picture.) Datalog is not really a query language, actually. But it is relational, like SQL, so it lets you express relations between "facts" (the rows) inside tables. But it is more general, because it also lets you express relations between tables themselves (e.g. this "table" is built from the relationship between two smaller tables), and it does so without requiring extra special case semantics like VIEWs. Because of this, it's easy to write small fragments of Datalog programs, and then stick it together with other fragments, without a lot of planning ahead of time, meaning as a language it is very compositional. This is one of the primary reasons why many people are interested in it as a SQL alternative; aside from your typical weird SQL quirks that are avoided with better language design (which are annoying, but not really the big picture.)

thenaturalist 2y ago
> but it is more general, because it also lets you express relations between tables themselves (e.g. this "table" is built from the relationship between two smaller tables), and it does so without requiring extra special case semantics like VIEWs. If I understand you correctly, you can easily get the same with ephemeral models in dbt or CTEs generally? > Because of this, it's easy to write small fragments of Datalog programs, and then stick it together with other fragments, without a lot of planning ahead of time, meaning as a language it is very compositional. This can be a benefit in some cases, I guess, but how can you guarantee correctness with flexibility involved? With SQL, I get either table or column level lineage with all modern tools, can audit each upstream output before going into a downstream input. In dbt I have macros which I can reuse everywhere. It's very compositional while at the same time perfectly documented and testable at runtime. Could you share a more specific example or scenario where you have seen Datalog/ Logica outperform a modern SQL setup? Generally curious. I am not at all familiar with the Logica/Datalog/Prolog world.

jyounker 2y ago

> No weird OOP-style class instantiation for something as simple as just getting the name. I understand the desire to no waste your time, but I think you're missing the big idea. Those statements define logical relations. There's nothing related to classes or OOP. Using those building blocks you can do everything that you can with SQL. No need for having clauses. No need for group by clauses. No need for subquery clauses. No need for special join syntax. Just what you see above. And you can keep going with it. SQL quickly runs into the limitations of the language. Using the syntax above (which is basically Prolog) you can construct arbitrarily large software systems which are still understandable. If you're really interested in improving as a developer, then I suggest that spend a day or two playing with a logic programming system of some sort. It's a completely different way of thinking about programming, and it will give you mental tools that you will never pick up any other way.

thenaturalist 2y ago
Really appreciate your response and perspective! Goes on the holidays list.

snthpy 2y ago

Have a look at PRQL [1] for analytical queries. That's exactly what it's designed for. Disclaimer: I'm a contributor. That said. I like Logica and Datalog. For me the main use case is "recursive" queries as they are simpler to express that way. PRQL has made some progress there with the loop operator but it could still be better. If you have any ideas for improvement, please reach out! 1: https://prql-lang.org/ https://prql-lang.org/