51 ms·

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 wi

by 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.
- from-nibly 2y ago
  Prolog et al is a real brain buster. As in it will break your spirits and build you back up better. I remember in college I was able to build a binary tree with 3 lines of code. And once you write the insert, the delete, search, and others just magically appear. It also frames your thinking about defining what you want rather than how to get it. If you really want to see the power of these kinds of languages look up Einstein's puzzle solved with prolog. The solution just magically comes out by entering the constraints of the puzzle.
  - rytis 2y ago
    I suppose something like this: https://stackoverflow.com/a/8270393 https://stackoverflow.com/a/8270393 ?
  - surgical_fire 2y ago
    I had to use Prolog in college, and while I never saw it in the wild - I at least never stumbled upon a scenario where prolog was the answer - I really enjoyed how I had to change how I looked at a problem in order to solve it in prolog.
- burakemir 2y ago
  Here is a proof that you can translate non-recursive datalog into relational algebra and vice versa: https://github.com/google/mangle/blob/main/docs/spec_explain_relational_algebra.md https://github.com/google/mangle/blob/main/docs/spec_explain... Since Logica is translated to SQL it should benefit from all the query optimistic goodness that went into the SQL engine that runs the resulting queries. I personally see the disadvantages of SQL in that it is not really modular, you cannot have libraries, tests and such. Disclosure: I wrote Mangle (the link goes to the Mangle repo), another datalog, different way of extending, no SQL translation but an engine library.
  - aseipp 2y ago
    Mangle looks very interesting, thanks for the share. In particular I love your GRPC demo, because it shows a prototype of something I've been thinking about for a long time: what if we did GraphQL, but with Datalog! Maybe we could call it LogiQL :) In particular many people talk a lot about concerns like optimizations across GraphQL plans and how they are expected to behave on underlying tables, but this is something that I think has seen a lot of research in the Datalog realm. And to top it off, even ignoring that, Datalog just feels much more natural to write and read after a bit of practice, I think. (Obviously you need to be in the pure fragment of datalog without recursion, but even then it might be feasible to add those features with termination criteria even if it's just "decrement an internal counter and if it hits zero throw a big error") What do you think the plans for the Rust implementation will be? That's probably the most likely place I'd use it, as I don't really use Go that much.
cess11 2y ago
Right, so that's what they claim, that you'll get small reusable pieces. But: "Logica compiles to SQL". With the caveat that it only kind of does, since it seems constrained to three database engines, probably the one they optimise the output to perform well on, one where it usually doesn't matter and one that's kind of mid performance wise anyway. In light of that quote it's also weird that they mention that they are able to run the SQL they compiled to "in interactive time" on a rather large dataset, which they supposedly already could with SQL. Arguably I'm not very good with Datalog and have mostly used Prolog, but to me it doesn't look much like a Datalog. Predicates seems to be variadic with named parameters, making variables implicit at the call site so to understand a complex predicate you need to hop away and look at how the composite predicates are defined to understand what they return. Maybe I misunderstand how it works, but at first glance that doesn't look particularly attractive to me. Can you put arithmetic in the head of clauses in Datalog proper? As far as I can remember, that's not part of the language. To me it isn't obvious what this is supposed to do in this query language.
- aseipp 2y ago
  For the record, I don't use Logica myself so I'm not familiar with every design decision or feature -- I'm not a Python programmer. I'm speaking about Datalog in general. > making variables implicit at the call site What example are you looking at? The NewsData example for instance seems pretty understandable to me. It seems like for any given predicate you can either take the implicit name of the column or you can map it onto a different name e.g. `date: date_num` for the underlying column on gdelt-bq.gdeltv2.gkg. Really it just seems like a way to make the grammar less complicated; the `name: foo` syntax is their way of expressing 'AS' clauses and `name:` is just a shorthand for `name: name` > In light of that quote it's also weird that they mention that they are able to run the SQL they compiled to "in interactive time" on a rather large dataset, which they supposedly already could with SQL. The query in question is run on BigQuery (which IIRC was the original and only target database for Logica), and in that setup you might do a query over 4TB of data but get a response in milliseconds due to partitioning, column compression, parallel aggregation, etc. This is actually really common for many queries. So, in that kind of setup the translation layer needs to be fast so it doesn't spoil the benefit for the end user. I think the statement makes complete sense, tbh. (This also probably explains why they wrote it in Python, so you could use it in Jupyter notebooks hooked up to BigQuery.)
joe_the_user 2y ago
It's very familiar to anyone who knows how to read it. "Anyone who know the system can easily learn it" he said with a sniff. Yes, the similarity to Prolog lets you draw on a vast pool of Prolog programmers out there. I mean, I studied a variety of esoteric languages in college and they were interesting (I can't remember if we got to prolog tbh but I know 1st logic pretty well and that's related). When I was thrown into a job with SQL, it's English language syntax made things really easy. I feel confident that knowing SQL wouldn't oppositely make learning Prolog easy (I remember Scala later and not being able to deal with it's opaque verbosity easily). Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake.
- jyounker 2y ago
  > Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake. The flip side of that is SQL makes hard things nearly impossible. SQL doesn't have facilities for abstraction, and it doesn't compose, and this has consequences that I deal with daily. The lack of abstract facilities makes it hard to construct complicated queries, it makes it hard to debug them, and it makes it hard refactor them. Instead of writing more complicated SQL queries, developers lean on the host languages to coordinate SQL calls, using the host language's abstraction facilities to cover for SQL's inadequacies.
  - joe_the_user 2y ago
    The flip side of that is SQL makes hard things nearly impossible. What about SQL syntax makes the hard things possible? I get that the actual language SQL is broken in all sorts of ways. But I don't see any reason to replace it with some opaque from get-go. I mean, what stops you from defining, say adjectives and using those for rough modularity. Say EXPENSIVE(T) means T.price > 0; Select name FROM books WHERE EXPENSIVE(books); Seems understandable.
    - geocar 2y ago

by aseipp 2y ago

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.

from-nibly 2y ago
Prolog et al is a real brain buster. As in it will break your spirits and build you back up better. I remember in college I was able to build a binary tree with 3 lines of code. And once you write the insert, the delete, search, and others just magically appear. It also frames your thinking about defining what you want rather than how to get it. If you really want to see the power of these kinds of languages look up Einstein's puzzle solved with prolog. The solution just magically comes out by entering the constraints of the puzzle.
- rytis 2y ago
  I suppose something like this: https://stackoverflow.com/a/8270393 https://stackoverflow.com/a/8270393 ?
- surgical_fire 2y ago
  I had to use Prolog in college, and while I never saw it in the wild - I at least never stumbled upon a scenario where prolog was the answer - I really enjoyed how I had to change how I looked at a problem in order to solve it in prolog.
burakemir 2y ago
Here is a proof that you can translate non-recursive datalog into relational algebra and vice versa: https://github.com/google/mangle/blob/main/docs/spec_explain_relational_algebra.md https://github.com/google/mangle/blob/main/docs/spec_explain... Since Logica is translated to SQL it should benefit from all the query optimistic goodness that went into the SQL engine that runs the resulting queries. I personally see the disadvantages of SQL in that it is not really modular, you cannot have libraries, tests and such. Disclosure: I wrote Mangle (the link goes to the Mangle repo), another datalog, different way of extending, no SQL translation but an engine library.
- aseipp 2y ago
  Mangle looks very interesting, thanks for the share. In particular I love your GRPC demo, because it shows a prototype of something I've been thinking about for a long time: what if we did GraphQL, but with Datalog! Maybe we could call it LogiQL :) In particular many people talk a lot about concerns like optimizations across GraphQL plans and how they are expected to behave on underlying tables, but this is something that I think has seen a lot of research in the Datalog realm. And to top it off, even ignoring that, Datalog just feels much more natural to write and read after a bit of practice, I think. (Obviously you need to be in the pure fragment of datalog without recursion, but even then it might be feasible to add those features with termination criteria even if it's just "decrement an internal counter and if it hits zero throw a big error") What do you think the plans for the Rust implementation will be? That's probably the most likely place I'd use it, as I don't really use Go that much.

cess11 2y ago

Right, so that's what they claim, that you'll get small reusable pieces. But: "Logica compiles to SQL". With the caveat that it only kind of does, since it seems constrained to three database engines, probably the one they optimise the output to perform well on, one where it usually doesn't matter and one that's kind of mid performance wise anyway. In light of that quote it's also weird that they mention that they are able to run the SQL they compiled to "in interactive time" on a rather large dataset, which they supposedly already could with SQL. Arguably I'm not very good with Datalog and have mostly used Prolog, but to me it doesn't look much like a Datalog. Predicates seems to be variadic with named parameters, making variables implicit at the call site so to understand a complex predicate you need to hop away and look at how the composite predicates are defined to understand what they return. Maybe I misunderstand how it works, but at first glance that doesn't look particularly attractive to me. Can you put arithmetic in the head of clauses in Datalog proper? As far as I can remember, that's not part of the language. To me it isn't obvious what this is supposed to do in this query language.

aseipp 2y ago
For the record, I don't use Logica myself so I'm not familiar with every design decision or feature -- I'm not a Python programmer. I'm speaking about Datalog in general. > making variables implicit at the call site What example are you looking at? The NewsData example for instance seems pretty understandable to me. It seems like for any given predicate you can either take the implicit name of the column or you can map it onto a different name e.g. `date: date_num` for the underlying column on gdelt-bq.gdeltv2.gkg. Really it just seems like a way to make the grammar less complicated; the `name: foo` syntax is their way of expressing 'AS' clauses and `name:` is just a shorthand for `name: name` > In light of that quote it's also weird that they mention that they are able to run the SQL they compiled to "in interactive time" on a rather large dataset, which they supposedly already could with SQL. The query in question is run on BigQuery (which IIRC was the original and only target database for Logica), and in that setup you might do a query over 4TB of data but get a response in milliseconds due to partitioning, column compression, parallel aggregation, etc. This is actually really common for many queries. So, in that kind of setup the translation layer needs to be fast so it doesn't spoil the benefit for the end user. I think the statement makes complete sense, tbh. (This also probably explains why they wrote it in Python, so you could use it in Jupyter notebooks hooked up to BigQuery.)

joe_the_user 2y ago

It's very familiar to anyone who knows how to read it. "Anyone who know the system can easily learn it" he said with a sniff. Yes, the similarity to Prolog lets you draw on a vast pool of Prolog programmers out there. I mean, I studied a variety of esoteric languages in college and they were interesting (I can't remember if we got to prolog tbh but I know 1st logic pretty well and that's related). When I was thrown into a job with SQL, it's English language syntax made things really easy. I feel confident that knowing SQL wouldn't oppositely make learning Prolog easy (I remember Scala later and not being able to deal with it's opaque verbosity easily). Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake.

jyounker 2y ago
> Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake. The flip side of that is SQL makes hard things nearly impossible. SQL doesn't have facilities for abstraction, and it doesn't compose, and this has consequences that I deal with daily. The lack of abstract facilities makes it hard to construct complicated queries, it makes it hard to debug them, and it makes it hard refactor them. Instead of writing more complicated SQL queries, developers lean on the host languages to coordinate SQL calls, using the host language's abstraction facilities to cover for SQL's inadequacies.
- joe_the_user 2y ago
  The flip side of that is SQL makes hard things nearly impossible. What about SQL syntax makes the hard things possible? I get that the actual language SQL is broken in all sorts of ways. But I don't see any reason to replace it with some opaque from get-go. I mean, what stops you from defining, say adjectives and using those for rough modularity. Say EXPENSIVE(T) means T.price > 0; Select name FROM books WHERE EXPENSIVE(books); Seems understandable.
  - geocar 2y ago