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

41–50 of 67 posts

Re: Logica – Declarative logic programming language for data

#41

Post by geocar »

joe_the_user wrote: post #29
jyounker wrote: post #25

Earlier quoted context omitted.

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

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

Isn't that just WITH?

    WITH expensive AS (SELECT * FROM books WHERE price > 100)
    SELECT name FROM expensive

Re: Logica – Declarative logic programming language for data

#42

Post by puzzledobserver »

avodonosov wrote: post #26

> Composite(a * b) distinct :- ... Wait, does Logica factorize the number passed to this predicate when unifying the number with a * b? So when we call Composite (100) it automatically tries all a's and b's who give 100 when m7ltiplied I'd be curious to see the SQL it transpiles to.

As someone who is intimately familiar with Datalog, but have not read much about Logica:

The way I read these rules is not from left-to-right but from right-to-left. In this case, it would say: Pick two numbers a > 1 and b > 1, their product a*b is a composite number. The solver starts with the facts that are immediately evident, and repeatedly apply these rules until no more conclusions are left to be drawn.

"But there are infinitely many composite numbers," you'll object. To which I will point out the limit of numbers Datalog is usually defined using what is called set semantics. In other words, tuples are either derivable or not. A cursory inspection of the page seems to indicate that Logica works over bags / multisets. The distinct keyword in the rule seems to have something to do with this, but I am not entirely sure.

This reading of Datalog rules is commonly called bottom-up evaluation. Assuming a finite universe, bottom-up and top-down evaluation are equivalent, although one approach might be computationally more expensive, as you point out.

In contrast to this, Prolog enforces a top-down evaluation approach, though the actual mechanics of evaluation are somewhat more complicated.

Re: Logica – Declarative logic programming language for data

#43

Post by usgroup »

Its nice to see Logica has come on a bit. A year or two ago I tried to use this in production and it was very buggy.

The basic selling point is a compositional query language, so that over-time one may have a library of re-usable components. If anyone really has built such a library I'd love to know more about how it worked out in practice. It isn't obvious to me how those decorators are supposed to compose and abstract on first look.

Its also not immediately obvious to me how complicated your library of SQL has to be for this approach to make sense. Say I had a collection of 100 moderately complex and correlated SQL queries, and I was to refactor them into Logica, in what circumstances would it yield a substantial benefit versus (1) doing nothing, (2) creating views or stored procedures, (3) using DBT / M4 or some other preprocessor for generic abstraction.

Re: Logica – Declarative logic programming language for data

#44

Post by usgroup »

dang wrote: post #2

Related: Google is pushing the new language Logica to solve the major flaws in SQL - https://news.ycombinator.com/item?id=29715957 - Dec 2021 (1 comment) Logica, a novel open-source logic programming language - https://news.ycombinator.com/item?id=26805121 - April 2021 (98 comments)

I may be misremembering but I think that at the time, Logica was the work of one developer who happened to be at Google. I'm not sure that there was an institutional push to use this language, nor that it has significant adoption at Google itself.

Re: Logica – Declarative logic programming language for data

#45

Post by thenaturalist »

usgroup wrote: post #43

Its nice to see Logica has come on a bit. A year or two ago I tried to use this in production and it was very buggy. The basic selling point is a compositional query language, so that over-time one may have a library of re-usable components. If anyone really has built such a library I'd love to know more about how it worked out in practice. It isn't obvious to me how those decorators are supposed to compose and abstr…

Never heard of M4 before and, lo and behold, of course HN has a discussion of it: https://news.ycombinator.com/item?id=34159699

The author discusses Logica vs. plain SQL vs POSIX.

I’d always start with dbt/ Sqlmesh.

The library you’re talking about exists: dbt packages.

Check out hub.getdbt.com and you’ll find dozens of public packages for standardizing sources, data formatting or all kinds of data ops.

You can use almost any query engine/ DB out there.

Then go for dbt power user in VS Code or use Paradime and you have first class IDE support.

I have no affiliation with any of the products, but from a practitioner perspective the gap between these technologies (and their ecosystems) is so large that the ranking of value for programming is as clear as they come.

Re: Logica – Declarative logic programming language for data

#46

Post by thenaturalist »

usgroup wrote: post #44
dang wrote: post #2

Related: Google is pushing the new language Logica to solve the major flaws in SQL - https://news.ycombinator.com/item?id=29715957 - Dec 2021 (1 comment) Logica, a novel open-source logic programming language - https://news.ycombinator.com/item?id=26805121 - April 2021 (98 comments)

I may be misremembering but I think that at the time, Logica was the work of one developer who happened to be at Google. I'm not sure that there was an institutional push to use this language, nor that it has significant adoption at Google itself.

This seems supported by the fact that the repo is not under a Google org and it has a single maintainer.

Re: Logica – Declarative logic programming language for data

#47

Post by thenaturalist »

jyounker wrote: post #24
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…

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

Really appreciate your response and perspective!

Goes on the holidays list.

Re: Logica – Declarative logic programming language for data

#49

Post by thom »

thenaturalist wrote: post #45
usgroup wrote: post #43

Its nice to see Logica has come on a bit. A year or two ago I tried to use this in production and it was very buggy. The basic selling point is a compositional query language, so that over-time one may have a library of re-usable components. If anyone really has built such a library I'd love to know more about how it worked out in practice. It isn't obvious to me how those decorators are supposed to compose and abstr…

Never heard of M4 before and, lo and behold, of course HN has a discussion of it: https://news.ycombinator.com/item?id=34159699 The author discusses Logica vs. plain SQL vs POSIX. I’d always start with dbt/ Sqlmesh. The library you’re talking about exists: dbt packages. Check out hub.getdbt.com and you’ll find dozens of public packages for standardizing sources, data formatting or all kinds of data ops. You can use a…

M4 is absolutely ancient, one of those things you've probably only seen flashing by on your screen if you've found yourself running `make; make install`. I suppose it is a perfectly cromulent tool for SQL templating but you're right that you must be able to get more mileage out of something targeted like dbt/SQLMesh.

Re: Logica – Declarative logic programming language for data

#50

Post by cess11 »

Agraillo wrote: post #18

I think it is a good direction imho. Once being familiar with SQL I learned Prolog a little and similarities struck me. I wasn't the first one sure, and there are others who summarized it better than me [1] (2010-2012): Each can do the other, to a limited extent, but it becomes increasingly difficult with even small increases in complexity. For instance, you can do inferencing in SQL, but it is almost entirely manual…

Perhaps you already know this, but as a data store Prolog code is actually surprisingly convenient sometimes, similar to how you might create a throwaway SQLite3 or DuckDB for a one-off analysis or recurring batched jobs.

It's trivial to convert stuff like web server access logs into Prolog facts by either hacking the logging module or running the log files through a bit of sed, and then you can formalise some patterns as rules and do rather nifty querying. A hundred megabytes of RAM can hold a lot of log data as Prolog facts.

E.g. '2024-11-16 12:45:27 127.0.0.1 "GET /something" "Whatever User-Agent" "user_id_123"' could be trivially transformed into 'logrow("2024-11-16", "12:45:27", "127.0.0.1", "GET", "/something", "Whatever User-Agent", "user_id_123").', especially if you're acquainted with DCG:s. Then you could, for example, write a rule that defines a relation between rows where a user-agent and IP does GET /log_out and shortly after has activity with another user ID, and query out people that could be suspected to use several accounts.

Post reply on HN