Ask HN: What's Prolog like in 2024?

I have been interested in Prolog since my time at the University, and I loved the idea of logic programming.

For "proper" Prolog, in 2024 it is a niche language alive in specific constraint solving applications, but not really used outside of that. I haven't seen anyone attempting at using prolog as a general purpose language since the 90'.

Datalog and logic-inspired languages tend to pop up here and there as domain-specific languages.

Rego is a recent incarnation which had good adoption for k8s and other "modern" systems. However, when trying to get people in my org to adopt it in practice, I saw engineers struggle with the paradigm when complexity grows to more than toy problems.

Compiling Datalog to SQL with Logica is possibly the easiest path if you need a production ready open source Datalog setup (i.e. choose your favourite managed Postgres provider): https://logica.dev/

Don't forget the Datalog subset!

In the 2000s I was interested in inference over RDF and wanted something a bit more than RDFS and OWL and found out about Datalog:

https://en.wikipedia.org/wiki/Datalog

There wasn't a lot of literature on it or implementations then but a few years later people realized it's a great query language for complex queries that does a great job on transitive closures, can do math (unlike OWL which won't do it because Gödel proved first order logic + math is a hot mess)

I took a comparative programming languages course circa 1993, the instructor thought that that Prolog was a taste of the future of programming. At first I thought the way you can implement ordinary procedural code in Prolog was really clever but if you write very much of it I think it is awkward; for instance it is common to treat procedural success as a logical failure because that gets the behavior you want.

It's counterintuitive that you could write a reasonably fast interpreter for Prolog but Warren figured out how to do it and it really is a neat trick. In the 1980s the Japanese Fifth Generation project dreamed about parallel Prolog on a machine with 100s of CPUs but it was discovered pretty quickly that you couldn't really parallelize Prolog execution so they came up with the less expressive language

https://en.wikipedia.org/wiki/KL1

I am amused to see papers today where people are working on tasks similar to what they worked on in that project, parallelizing them with commodity hardware, and get scaling curves that look very similar to what was done with KL1. (In the end the 5GP settled on the same message-passing architecture that everybody else did until the GPU revolution came)

One of the nicest examples in Prolog is writing a parser by just writing the productions which works because Prolog's resolver is quite similar to a common parsing algorithm. In the large however, you can add a library to a normal programming language like Python or Java where you write the same grammar in a DSL and it is handled by the library.

See also production rules systems which use "forward chaining" with the RETE algorithm and variants for an approach which looks like Prolog in some ways but works in the reverse direction. My favorite example of this now is

http://www.clara-rules.org/

I built a prototype of a stream processing engine where the control plane was implemented as a set of production rules that would build a processing pipeline of reactive operators, key-value and triple stores and then tear it down. Unlike another stream processing engine I worked on, mine always got the right answers. I think a production rule system could be the target of a "low code" system. I'm a little disappointed that I've never seen a Javascript framework that uses production rules because they are a great answer to asynchronous communication choreography. (See complex event processing)

DataScript, Datahike, Datalevin, and XTDB 1.x are open-source. (XTDB 2.x is also open-source but has switched from Datalog to its own query language and SQL.) DataScript, Datalevin, and XTDB have been used in production; not sure about Datahike. All of these databases come from the Clojure community and target Clojure as the primary language. The XTDB team has published a comparison matrix at https://clojurelog.github.io/.

Aside: I write a lot more Python than Clojure, and I wish someone ported Datalevin/Datahike/persistent DataScript to Python. I'd try it as an alternative to SQLite. I suspect with thoughtful API design, an embedded Datalog could feel organic in Python. It might be easier to prototype with than SQLite. There are Datalog and miniKanren implementations for Python, but they are not designed as an on-disk database. PyCozo might be the closest thing that exists. (A sibling comment https://news.ycombinator.com/item?id=40995652 already mentions Cozo.)

> Prolog uses depth-first search and backtracking, which can lead to infinite loops if the rules are not carefully ordered

Is this an issue in practice? Most languages can create programs with infinite loops, but it's easy to spot in code reviews. It's been over a decade since I encountered an infinite loop in production in the backend. Just wondering if the same is true for Prolog.