As someone who has developed a somewhat weird obsession with Prolog, I can highly recommend Markus Triska's other articles on Prolog. His article on meta-interpreters [0] was particularly inspiring for me.
[0] https://www.complang.tuwien.ac.at/ulrich/prolog_misc/acomip....
There's something quite illuminating with this first "horror", where they basically say "it's OK to report wrong answers, because you can check the answers".
I don't think I've ever felt like it's OK for my program to provide a list of answers where some are right and some are wrong, but reading this... and generally believing in P != NP.... maybe that's a decent way of looking at some stuff!
I've actually run into this in the wild, with regards to sales forecasting. A program we were using returned zero if the error bars on a forecast were over 100%. For example, selling somewhere between 1 and 7 units, but averaging 3.
Returning 3 was "wrong", but infinitely more correct than retuning 0.
The article server is offline, but I assume they found out that prolog rule evaluation depends on the order the rules are presented in the program.
If so, the language they thought they were using (and that they should actually use) is datalog, not prolog.
Datalog has declarative semantics: All facts that are derivable from the base database and the rules will be derived by the interpreter, and it will not add extra hallucinated facts. If that's not true, it's a bug in the runtime, not in the language.
www.metalevel.at is run by Prolog legend Markus Triska, author of CLP(FD)/CLP(Z).
So it's not that they "discovered" anything about Prolog; they already knew the language inside out.
This article explains how to appropriately use Prolog declaratively and with full generality.
iirc, shor's algorithm for factoring relies on this.
Sometimes the Biorhythm program on my Apple ][ failed to produce correct answers. But it sure was great for impressing cool hippie chicks.
If you want to understand prolog, you must understand the four-port model:
And to understand the four-port model is to understand solution-space navigation and pruning.
It's why smartphones lost all their ports: forbidden knowledge must not be leaked to the public.
> ... forbidden knowledge must not be leaked to the public.
Understanding is a personal achievement and has nothing to do with "forbidden knowledge" when the source of said knowledge is both quoted above and freely available.
What do people use Prolog for in the real world? I learned about it on a university course and it seems so esoteric compared to other things on the course. Like something invented just for computer scientists to enjoy.
Some applications were discussed in https://news.ycombinator.com/item?id=40994552
Dunno about Prolog, but Datomic uses datalog for its query language, and it’s excellent. Datalog is a subset of Prolog.
Datalog may appear to be a subset, but it is quite distinct semantically.
What is Datalog used for nowadays?
General programming [0], static analysis [1], RDF triple stores [2], authorization systems [3], incremental computation [4] [5], graph DBs [6]. But it is kind of hard to define Datalog exactly, since it is an entire family of technologies based on logic, each extending a clean mathematical model differently.
[0] https://github.com/flix/flix
[1] https://github.com/rust-lang/polonius
[2] RDFox
[3] https://github.com/eclipse-biscuit/biscuit
[4] https://github.com/vmware-archive/differential-datalog [5] https://github.com/brurucy/pydbsp
Other than databases, program analysis. The polonius borrow checker in rustc uses datalog internally.
But you can use it for lots of things. Whenever I'm frustrated with graph based tools being slow (like build systems), I run the graph through a datalog engine for comparison. It's usually much, much faster.
Datalog is not a subset of Prolog. It looks that way because both are based on Horn clause logic, while Prolog is more expressive.
This loops Prolog, but terminates in Datalog:
p :- p.
p.
?- p.
This is because the underlying mechanism is completely different. Datalog is like SQL with recursion, you start with known facts and repeatedly applies rules to derive all consequences until nothing new appears. In Prolog, you start from the query and works backward through rules until it either finds a proof or fails.
So, Datalog treats Horn clauses as database constraints/inference rules while Prolog treats Horn clauses as a search program. They use the same mathematical substrate, but completely different computational models.
Everything, you heard the joke about those who don't know Lisp end up reinventing it, well, the same can be said for Prolog.
20+ years ago, it was the backend for the business rules engine that processed various logging and monitoring events. The concept was interesting, the performance was terrible, and businesses mostly didn't want to touch it. After I setup clients with a generic set of rules that worked on Prolog facts, most all of my clients were happy to limit their changes to only those fact files.
> What do people use Prolog for in the real world?
Here[0] is an example of using Ruby and Prolog to solve a real-world AWS management problem.
0 - https://web.archive.org/web/20190525163234/https://dev.to/da...
That is brilliant and simple and shows that when Graph Databases were a big thing they probably should have used Prolog as a front end.
now we may have a more powerful "Prolog" - LLM Agent, though not precise and correct somtimes.
Mostly overblown.