Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Logica – Declarative logic programming language for data

logica.dev

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Logica – Declarative logic programming language for data

#31

Post by kthejoker2 »

aseipp wrote: post #15
thenaturalist wrote: post #9

Earlier quoted context omitted.

> 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…

> If I understand you correctly, you can easily get the same with ephemeral models in dbt or CTEs generally? You can bolt on any number of 3rd party features or extensions to get some extra thing, that goes for any tool in the world. The point of something like Datalog is that it can express a similar class of relational programs that SQL can, but with a smaller set of core ideas. "Do more with less." > I guess, but…

CTEs aren't really an "extra" feature they just are a composable reusable subquery. This just adds the benefit of storing CTEs as function calls aka table valued functions (TVFs) ... also not really an "extra" feature.

The main advantage to any non SQL language is its ability to more efficiently express recursion (graph / hierarchical queries) and dynamic expressions like transposition and pivots.

You can do those in SQL it's just clunky.

Re: Logica – Declarative logic programming language for data

#32

Post by FridgeSeal »

taeric wrote: post #16

I find the appeals to composition tough to agree with. For one, most queries begin as ad hoc questions. And can usually be tossed after. If they are needed for speed, it is the index structure that is more vital than the query structure. That and knowing what materialized views have been made with implications on propagation delays. Curious to hear battle stories from other teams using this.

Depends who your users are and what the context is.

Having been in quite a few data teams, and supported businesses using dashboards, a very large chunk of the time, the requests do align with the composable feature: people want “the data from that dashboard but with x/y/z constraints too” or “ who did a|b in the last time, and then send that to me each week, and then break it down by something-else”. Scenarios that all benefit massively from being able to compose queries more easily, especially as things like “well defined customer segment” get evolved. Even ad-hoc queries would benefit because you’d be able to throw them together faster.

There’s a number of tools that proclaim to solve this, but solving this at the language level strikes me as a far better solution.

Re: Logica – Declarative logic programming language for data

#34

Post by taeric »

FridgeSeal wrote: post #32
taeric wrote: post #16

I find the appeals to composition tough to agree with. For one, most queries begin as ad hoc questions. And can usually be tossed after. If they are needed for speed, it is the index structure that is more vital than the query structure. That and knowing what materialized views have been made with implications on propagation delays. Curious to hear battle stories from other teams using this.

Depends who your users are and what the context is. Having been in quite a few data teams, and supported businesses using dashboards, a very large chunk of the time, the requests do align with the composable feature: people want “the data from that dashboard but with x/y/z constraints too” or “ who did a|b in the last time, and then send that to me each week, and then break it down by something-else”. Scenarios that…

I supported a team at a large company looking at engagement metrics for emails. Materialized views (edit: manually done) and daily aggregate jobs over indexed ranges was really the only viable solution. You could tell the new members because they would invariably think to go to base data and build up aggregates they wanted, and not look directly for the aggregates.

That is so say, you have to define the jobs that do the aggregations, as well. Knowing that you can't just add historical records and have them immediately on current reports.

I welcome the idea that a support team could use better tools. I suspect polyglot to win. Ad hoc is hard to do better than SQL. DDL is different, but largely difficult to beat SQL, still. And job description is a frontier of mistakes.

Re: Logica – Declarative logic programming language for data

#35

Post by kukkeliskuu »

foobarqux wrote: post #21

There don't seem to be any examples of how to connect to an existing (say sqlite) database even though it says you should try logica if "you already have data in BigQuery, PostgreSQL or SQLite,". How do you connect to an existing sqlite database?

I was turned off by this at first, but then tried it out. These are mistakes in the documentation. The tools just work with PostgreSQL and SQLite without any extra work.

Re: Logica – Declarative logic programming language for data

#37

Post by burakemir »

aseipp wrote: post #30
burakemir wrote: post #12

Earlier quoted context omitted.

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... 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…

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…

The Mangle repo has the beginnings of a Rust implementation but it will take some time before it is usable. The go implementation is also still being improved, but I think real DB work with persistent data will happen only in Rust. Bindings to other host languages would also use the Rust implementation. There are no big challenges here it is just work and takes time.

The combination of top-down and bottom up logic programming is interesting, especially when one can move work between pre computation and query time.

I like that optimizing queries in datalog can be discussed like optimization of programming language but of course the biggest gains in DB come from join order and making use of indices. There is a tension here between declarative and having some control or hints for execution. I haven't yet figured out how one should go about it, and also how to help programmers combine top-down and bottom-up computation. Work in progress! :-)

Re: Logica – Declarative logic programming language for data

#39

Post by snthpy »

thenaturalist wrote: post #6

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.na…

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/

Re: Logica – Declarative logic programming language for data

#40

Post by cess11 »

aseipp wrote: post #20
cess11 wrote: post #13

Earlier quoted context omitted.

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 ar…

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 m…

They define a NewsData/5, but use a NewsData/2.

Are you aware of any SQL transpilers that spend so much time transpiling that you get irritated? I'm not.

Post reply on HN