An Overview of Datalog (2010)
clojure.github.io
clojure.github.io
My own humble attempt is here https://github.com/google/mangle ... I had come across datalog in Clojure and thought it is a complete nonstarter. Most people (including me) are not in a position to start using Clojure if all they want is a query capability.
IMHO what most people would want a datalog implementation that is very easy to integrate into their existing setup, with their existing data. Yet for extensibility it is also important to enable users to write datalog queries in it's own special syntax so one can have type checking, modules, declarations in a way that is independent of the host programming language.
From a teaching point of view, one does need an example database. Here is "employee department boss", with a volunteering spin: https://github.com/google/mangle/blob/main/docs/example_volu...
There is a long history of approaches to integrate querying into programming languages (eg LINQ). Trade off here between making an easy to use yet powerful query language, keeping it simple and integrating it tightly into the host language or using a DSL along clear interface.
I tried them out for a pet project over here: https://er4hn.info/blog/2024.05.08-biscuits/ and was pretty impressed with what I found. It's not a perfect solution, but I liked it a lot more than OAuth.
https://news.ycombinator.com/item?id=41322281
>Under the hood we save data to postgres as triples and wrote a datalog engine for fetching data [3]. We don’t expect you to write datalog queries so we wrote a graphql-like query language that doesn’t require any build step.
Datalog has a simple syntax, and implementing a basic triple store is relatively straight forward. This let us build out a) a client-side store, b) an invalidation engine, and c) a multi-tenant triple store, with a team of 5.
Clojure's syntax for datalog is especially amenable too, because the language is expressed as a datastructure. We often 'build' up queries, and having the language expressed as a data structure helps us do that.
We talk about the design journey here: https://www.instantdb.com/essays/next_firebase#exploring-sql
If you're interesting in implementing one yourself, I particularly like this chapter in SICP:
https://sarabander.github.io/sicp/html/4_002e4.xhtml#g_t4_00...
The climbing idea for example from the other thread...
But I need to formulate my use case more clearly.
I am super interested in the "iterating" you did with AJ at Subset.so -- as thats a neato thing.
My climbing idea was predicated on an idea of forking an AppID (like from your demos) whereby if I can have a class of an app that is forkable -- then others can have the same copy of my app, but they could be linked...
Actually imma reach out to you guys because I (in typing this) just formulated what I want to build with this :-)
Ill need some iterating hand-holding like subset has. :-)
HN is so amazing.
{EDIT - I just saw that the original post on datalog is from 2010! oops. I thought it was someone writing up their own thing on it...}
For recursion it can be elegant, but a graph query language like Cypher is much easier to work with.
Less verbose than SQL but also much less readable.
I think Rust was initially using it for reference counting.
But it is no SQL killer or Cypher killer.
I’ve only ever seen it used in Clojure(Script) projects although there’s support in other languages too.
IBM's get-it-out-the-door release of partial (if not broken) implementation of Codd's relational-algebra model, which incorporates parts of predicate-logic, set-theory, and more besides. It kicked-off an industrywide multivendor revolution in information storage, processing, and retrieval.
...but thesedays I'm convinced the point of SQL is to have something other programming languages can point-to to deflect any criticisms of being slow or unwilling to adopt new features, being specifically unergonomic, or most of all: being entirely unresponsive to the day-to-day needs of present-day application developers.