I have also used SwiProlog and occasionally Amzi Prolog also since then. SwiProlog’s semantic Web library was the basis for all my early work and experience with semantic Web and linked data. I definitely suggest trying Prolog on a few small projects and add it to your tool set.
If I understand it right, Prolog is being used kind of like a more powerful version of Awk / Perl. The Power of Prolog  describes a somewhat similar use of Prolog: storing server logs as Prolog terms and then running complex queries directly on the log files.
I have limited experience with Prolog, but it is not just a quick and dirty scripting language (how I view Perl). They were able to build the system so fast, because they only needed to translate the customer's requirements into Prolog declarations, and the Prolog engine is powerful enough to solve the constraints. In my experience, imperative code rarely has a 1-to-1 relationship with the requirements like this.
In fact it's a better prolog, picat, which also allows pretty straightforward statements, like loops, and has solver support.
1) personally I think Prolog is much more broadly applicable in all kinds of apps rather than just type inference, policy languages, games; but with the recent rise of Datalog as actual query and inference language (and not just in academic database literature), it seems Prolog's time has finally come
writing prolog is mostly about writing in the most natural and readable syntax possible. using haskell-like types put me off.
It's a biig discussion and I'm not the one to make the argument for CLP, but, for example, in straight-up Prolog arithmetic is implemented using the is/2 predicate, which looks a bit like this:
A is 1 + 2.
X #= 1+2.
?- 3 #= Y+2.
Y = 1.
?- X #= A + B, A in 1..3, B in 4..6.
X in 5..9,
A in 1..3,
B in 4..6.
You can find more information in the CLP(FD) library documentation, here:
Or, if Markus Triska (the author of the library) is around, he can probably elucidate its use a bit better than I can :)
1. > An initial analysis found that we would need to implement a complex depth/breadth search algorithm either in the client application or in SQL.
2. The Prolog runtime would efficiently solve this problem given rules that naively described it.
I am skeptical, as this is emphatically not my experience with Prolog. In my experience, for any problem requiring a complex search strategy, Prolog is not your friend. Most Prologs do something approximating a naive depth-first search with unification, and on complex search problems this approach rapidly blows up. This can _sometimes_ be fixed by:
1. Making careful use of cut (`!`) or other non-declarative operators to change the search order.
2. Using tabling, essentially an advanced form of memoization. But only some Prologs support tabling, and it's useful only for some sorts of problem.
However, the author mentions none of these. Are they glossing over something, or is my (probably more limited) Prolog experience uncharacteristic? Are there "smart" Prologs out there I'm unaware of?
The implementation I used was SWI-Prolog. I had tinkered with a couple of others prior to that in school (sorry, I don't remember more details), but this was free/open, and up to the job at hand without requiring an acquisition process from the customer of the system.
About the search strategy; yes I had to use a few cuts to get acceptable efficiency. Still, this was much easier than re-creating the same thing in SQL or imperative application code. The particular details, I don't remember well; sadly I've had little occasion since 2010 to use Prolog.
Without knowing the details of the problem it's hard to be sure, of course. Combinatorial explosion can make even searches involving a rather small number of choices take impractically long to finish. But that depends on the structure of the search problem.
Edit: The author says in the comments on the original post that he used SWI Prolog, which I believe doesn't do anything special in its search strategy, although it does have support for CLP.
I've used prolog on production systems, there's odbc drivers, he could have connected directly to the DB and ran his rules. Checkout the swiprolog libs, they are quite extensive
Most modern Prologs use indexing on predicates' symbols and arguments to speed up queries and the days when Prolog was a "slow" language are long gone by.
As to the search strategy, it's a bog-standard, depth-first search (no approximation). Unification is part of the theorem-proving algorith, SLD-resolution. Depth-first search is used to find "resolvents", i.e. candidates for resolution (ish).
The parent post describes a backward-chaining problem, where rules must be selected depending on their arguments, most likelly to perform some complex reasoning procedure. In that context, search is required to select relevant rules at each step of the reasoning process- not, say, to search a large database for all records of persons with a name starting from "m".
For this kind of use-case, Prolog's search is not only perfectly adequate, but also nearly perfectly optimised, due to long years of development as a language.
That said, "searching a database for all records starting from m" is very much like searching for resolvents and thanks to modern practices, like indexing, Prolog can do that kind of search just fine also.
I often want to reach for prolog when I face a problem like this, but I just don't know enough about how it degrades/breaks and of course don't want to use it to do any of the rest of the program stuff (web server, DB access), etc.
The semantics of OPA's policy language are based on Datalog, a non-Turing complete subset of Prolog. This means that all policy queries in OPA are guaranteed to terminate (which makes it a good fit for problems like authorization.)
Beyond regular Datalog, OPA adds first-class support for querying complex/nested data structures like JSON.
As a side note, OPA was not developed at Netflix, but they were one of the early adopters and continue to use it today.
Did you guys build your own engine? I took a quick look at the repo but don't see anything that looks like a datalog library in your glide package list.
Last but not least, thanks for making and open sourcing such an awesome tool! Will definitely be passing the word on about Styra, I had no idea there was a whole company/more efforts behind OPA. I plan on using OPA in a bunch of upcoming projects -- it looks like a fantastic, stable addition to the toolbox of people looking to build robust programs/services.
Yes, the language implementation (parser/compiler/evaluator) is implemented from scratch.
> Last but not least, thanks for making and open sourcing such an awesome tool!
Thanks for the kind words! If you have questions or need help, feel free to file issues on Github or ask questions on Slack.
There isn't always a good reason to use it for many situations nowadays but it the way you deal with graphs and trees and such is fantastic. Though fun fact Allegrograph has a Prolog rules interface
This is some serious latency between recording and writing a thing, and is appearing on hacker news. I will go through here and try to answer various questions etc.
There are a few problems that don't fit well with Prolog, but not many. For everything else, if you're not using Prolog you're probably working too hard.
Consider that achieving feature parity with 1/5th the code means 1/5th the bugs, right off the top.
But often Prolog code is more useful than some equivalent imperative code, for example, a Sudoku relation defined in Prolog serves to solve puzzles, but it can also generate new puzzles and verify partial puzzles (count the solutions and assert that there's only one.) https://swish.swi-prolog.org/p/Boring%20Sudoku.swinb
Prolog is also old.
I keep thinking, "What about FOO?", only to find that FOO has been explored years ago by a group of researchers, and often there is working code off-the-shelf and ready to go to solve whatever problem.
Anyhow, TL;DR: For goodness' sake please check out Prolog. It's like time-traveling into the future.