81–90 of 111 posts
This is an older presentation but its all about doing Datalog from the client to the DB.
See: https://www.youtube.com/watch?v=aI0zVzzoK_E
But if you go threw the Clojure world, there is Datalog all over the place, both client and server. Check out Datascript:
https://github.com/tonsky/datascript
This full-stack framework: http://book.fulcrologic.com/
Earlier quoted context omitted.
A few weeks ago, I was pondering over the pain involved in designing and implementing a REST api, for an simple backend. After much deliberation, it was clear to me that I dont understand the HATEOS part of REST and that I have been using the url as a filter and get or post parameters as variables for calling some functions on the backend server. And often, for an SPA, I would have to do multiple queeies in quick suc…
The complexity is just moved somewhere else; instead of being explicit in an API, it's implicit in a behaviour. If you want to permission those bits you're doing CRUD ops on, or refactor how they're stored, change their normalization in the database, split them out of a monolith into separate services, ensure you're not permitting the UI team (or worse, your customers writing direct to your API) take dependencies on…
GraphQL is excellent for when you’re implementing an external facing api or a data focused api.
Internal APIs where you also own the client or have operation (side effect) heavy clients. These imo would be far better suited to REST.
Earlier quoted context omitted.
To clarify: I mean that Prolog was under consideration to be used for what SPARQL was then developed, as a more readable and simpler query and also modeling language. Several researchers working in this area considered the development of SPARQL to be a missed opportunity for better formalisms, since Prolog could have been used instead . And, yes, to many who have worked with RDF, SPARQL and the various notations that…
> easily processable > formal reasoning based on well known logical rules Oof, I do not know any serious researcher of logic who would support that claim. Prolog is, due to its age and heritage, inherently side/effectful and undecidable/turing-complete. SPARQL has big fat warts, for sure, design by committee, bulky syntax, way too long spec, way too many capabilities, and questionable decidability (looking at you MAY…
But the claim I believe is that _Datalog_ is a subset of Prolog that is a query language. That claim is true by design.
Also, given bottom-up evaluation, Datalog programs are guaranteed to terminate and, restricted to definite clauses with no function symbols (of arity more than 0) they are also amenable to formal proofs of correctness, perhaps more so than Prolog itself.
EDIT: Oh. I assume that by "formal reasoning" you and triska are discussing formal proofs of correctness- otherwise I don't understand the disagreement. Resolution is a well-known logical rule (an inference rule) and it's amenable to formal reasoning, for sure.
Earlier quoted context omitted.
The big win of using GraphQL, at least for me, is not the performance, but the developer experience. I can craft a query in Graphiql, paste it into my application, and from there generate Flow types for the query response. Make a breaking change to my graphql API? Flow types will fail CI tests until I fix any dependent client code. All of this works pretty nicely out of the box, and it’s leaps and bounds better than…
You mean frontend developer experience. The backend developers I interact with are not too enthusiastic on moving the complexity from the frontend to the backend when using GQL.
Prolog (Datalog) has always been the gold standard for query languages. GraphQL is merely the latest attempt to reinvent it by people who obviously don't know what came before (or don't care). This might be because CS programs are no longer teaching Prolog, but I think it's more likely because one doesn't get career advancement points for using something "old" unless one reinvents it and renames it so it seems "new."
I know Prolog (from college) and SPARQL (from hobbyist dinking around with SemWeb). I love DSLs and weird languages. I should be almost the ideal Datalog user, so how did it stay completely off my radar until this post?
I'm only aware of it because a databases course taught it (relational algebra to datalog to SQL) and I thought it was superb, and a couple of times since I've tried to find if I can use it, but it seems to suffer from the combination of age + academia + proprietariness that makes such things hard to discover and use. (Compared to graphql and plethora of open source libs on Github, etc.)
Earlier quoted context omitted.
> easily processable > formal reasoning based on well known logical rules Oof, I do not know any serious researcher of logic who would support that claim. Prolog is, due to its age and heritage, inherently side/effectful and undecidable/turing-complete. SPARQL has big fat warts, for sure, design by committee, bulky syntax, way too long spec, way too many capabilities, and questionable decidability (looking at you MAY…
That's right- Prolog is not a query language. But the claim I believe is that _Datalog_ is a subset of Prolog that is a query language. That claim is true by design. Also, given bottom-up evaluation, Datalog programs are guaranteed to terminate and, restricted to definite clauses with no function symbols (of arity more than 0) they are also amenable to formal proofs of correctness, perhaps more so than Prolog itself.…
I object to datalog being viewed as a subset of prolog, other than for historical reasons. It's just not useful as both languages differ significantly in philosophy, properties and implemenentation.
Datalog program equality is undecidable btw so while it's certainly more amenable to correctness proofs than prolog (which isn't at all with it's undecidability and implementation definedness everywhere), you'd still want more restricted logics for that.
Which isn't to say that's a bad thing, often times you want that power, and you don't need the correctness proof.
Fun fact, DLLite can tell you that the shin bone is a bone, and it can do so 10 billion times a second, and verifiably correctly so ;)
Edit: Some systems that arguably implement a superset of Datalog, but for which their Datalog subset is not a subset of Prolog are LogicBlox, Datomic, Datascript and TriQ-Lite.
Earlier quoted context omitted.
The complexity is just moved somewhere else; instead of being explicit in an API, it's implicit in a behaviour. If you want to permission those bits you're doing CRUD ops on, or refactor how they're stored, change their normalization in the database, split them out of a monolith into separate services, ensure you're not permitting the UI team (or worse, your customers writing direct to your API) take dependencies on…
I think the issue is more with framing. GraphQL is excellent for when you’re implementing an external facing api or a data focused api. Internal APIs where you also own the client or have operation (side effect) heavy clients. These imo would be far better suited to REST.
Internal graphql api can be iterated and broken faster, adapting it for internal use as the app grows, while an external REST api would be more carefully generated and thoroughly documented.
It's not clear to me that GraphQL and Datalog solve the same problems. GraphQL, to me, is fundamentally about designing the interface between a client and server, decoupled from the logic that satisfies requests. I think it's actually not a query language at all, any more than HTTP is a query language. Datalog is very much a query engine. And it's not super clear to me that the services exposed by a server map cleanl…
For context, I'm a frontend development lead who oversees a number of projects of different shape and size. My personal and very subjective opinion is it's simply hype. If you say "Datalog" to a frontend developer, they will either hear "obsolete" or just not know what you mean. If you say "GraphQL", they hear "+5 CV points". Obviously that is slightly tongue in cheek, but the marketing side of it is a very real fact…
> I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through.
Look into how Gatsby.js uses GraphQL. You can query data from markdown files, configuration files (JSON) and resize images by specifying it in a query.
Earlier quoted context omitted.
> A great example for this is XSB Prolog, I'm really sorry but it honestly cannot be. I was curious because Datalog/Prolog based technologies are intriguing so I clicked on that link. https://xsb.com/xsb-prolog seems to have no download but links to http://xsb.sourceforge.net/ which claims version 3.8 (October 2017) is current and links to http://xsb.sourceforge.net/downloads/downloads.html which does not specify a v…
That sucks. XSB is old code and I believe it was meant mostly as a proof of concept even at the time it was written. I doubt many people use it, even in research, nowadays. I believe what triska meant about XSB is that it demonstrated the benefits of SLG resolution, by being a proof of concept like I say. So yes, XSB would be more of academic interest. If you want a modern Prolog to play around with you should try Sw…
Just gave the SWI implementation a try and that was honestly a much better experience and I could immediately jump on their getting started guides to get a feel. Thanks for the pointers as well, I've got a few colleagues that actively use prolog but good to see that there's an active community out there.
> EDIT: "halt." should work at any Prolog prompt. The "." is a statement terminator. You probably didn't get anything after "halt return" because you missed the dot.
Whoops. Yup, I think I might have, I was under the impression that dot in the documentation was the sentence delimiter.
(And btw, my bad about the Perl comment, I just realized when setting up the SWI one that they seem to share a file extension with Perl.)