My first time at RC, I would go down rabbit holes as long as its fun. This time at RC, I wanted to be more deliberate. In any case, extremes are bad. At least this is how I justified going from working on a series of Prolog exercises to thinking more broadly how things fit together.
In a previous post, the sample solution to the Dinesman puzzle highlights the declarative programming approach. In other words, the program describes the what, not the how. If you’re thinking “this sounds like SQL”, yes, it is very much like SQL. When you run a query in PostgreSQL, the query engine will figure out the scans and the joins, the optimizer speeds things up. You just supply the query.
In fact, this helpful diagram shows how Prolog relates to relational algebra (the theoretical basis for SQL). It’s from an Introduction to Datalog post, which is a highly-recommended read.
How does Datalog compare to Prolog? Prolog is a general-purpose (Turing-complete) language, whereas Datalog is the subset oriented around querying. Datalog seems limited as a subset but benefits in two ways. First, the order of clauses doesn’t matter. Second, Prolog works top-down by returning one result a time, whereas Datalog works with whole sets of data. Rich Hickey talks about Datalog as the query language for Datomic here.
How does Datalog compare to SQL? SQL is an implementation of relational algebra. Relational algebra does not support recursion, while certain SQL dialects extend this by allowing recursion through Common Table Expressions (CTEs). Rules in Prolog are allowed to be recursive but is much cleaner, or perhaps in the term that I’ve become rather fond of, much more ergonomic.