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?
Logica – Declarative logic programming language for data
21–30 of 67 posts
Re: Logica – Declarative logic programming language for data
#22Earlier quoted context omitted.
The syntax is Prolog-like, so people in the field are familiar with it.
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.
> 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.
Re: Logica – Declarative logic programming language for data
#23I 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…
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…
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.
Re: Logica – Declarative logic programming language for data
#24I 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 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.
Re: Logica – Declarative logic programming language for data
#25Earlier quoted context omitted.
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…
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 i…
> 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.
Re: Logica – Declarative logic programming language for data
#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.
Re: Logica – Declarative logic programming language for data
#27Earlier quoted context omitted.
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…
> 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…
The covid analysis seems like a pretty good example: https://colab.research.google.com/github/EvgSkv/logica/blob/...
A good exercise might be converting it to the corresponding SQL and comparing the two for clarity.
Re: Logica – Declarative logic programming language for data
#28Earlier quoted context omitted.
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…
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 i…
I mean, yes, that's sort of how linguistics works in general? You can't just look at a language with completely different orthography or semantic concepts and expect to be able to reliably map it onto your pre-existing language with no effort. That's sort of the whole reason translation is a generally difficult problem.
I don't really get this kind of complaint in general I'm afraid. Many people can read and write, say, Hangul just fine -- and at the same time we don't expect random English speakers with no familiarity will be able to understand Korean conversations, or any syllabic writing systems in general. Programming language families/classes like logic programming are really no different.
> it's English language syntax made things really easy
That's just called "being familiar with English" more than any inherent property of SQL or English.
Re: Logica – Declarative logic programming language for data
#29Earlier quoted context omitted.
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 i…
> 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 EXPENSIVE(books);
Re: Logica – Declarative logic programming language for data
#30Earlier 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…
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 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.