Live data from Hacker News

The Prolog Story (2010)

kylecordes.com

11–20 of 31 posts

Re: The Prolog Story (2010)

#12
post #9

I would like to know what Prolog implementation the author used. In particular, the article claims: 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…

(I am the author.)

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.

Re: The Prolog Story (2010)

#14
Summary: They needed to do some complex queries on data in a SQL database, queries that were clearly better suited for Prolog. So they 1) queried for the relevant data from SQL, 2) formatted the data into the form of Prolog terms and dumped it into a file, 3) fired up the Prolog interpreter and loaded the data along with a small amount of Prolog query code, 4) ran the Prolog queries, 5) formatted the results into CSV and dumped it into a file, and finally 6) imported the results back into SQL. While it has some hacky elements, this approach took just one day to implement, as opposed to the projected months it would have taken to do it without Prolog.

If I understand it right, Prolog is being used kind of like a more powerful version of Awk / Perl. The Power of Prolog [1] describes a somewhat similar use of Prolog: storing server logs as Prolog terms and then running complex queries directly on the log files.

[1] https://www.metalevel.at/prolog/business

Re: The Prolog Story (2010)

#15
Love seeing a good Prolog story surface. I was blown away by how productive it was to use back in university along with XPCE for UI. Became the first language I expertised in and it has paid off in terms of opening up a lot of other avenues like being able to easily learn Erlang and Elixir.

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

Re: The Prolog Story (2010)

#16

Prolog looks like the exact right language for at least some part of Netflix's OPA[0] -- I wonder why they didn't use it or why it wasn't a good fit (if someone considered it). 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. [0]: http:/…

(OPA co-founder here.)

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.

Re: The Prolog Story (2010)

#17

Summary: They needed to do some complex queries on data in a SQL database, queries that were clearly better suited for Prolog. So they 1) queried for the relevant data from SQL, 2) formatted the data into the form of Prolog terms and dumped it into a file, 3) fired up the Prolog interpreter and loaded the data along with a small amount of Prolog query code, 4) ran the Prolog queries, 5) formatted the results into CSV…

> Prolog is being used kind of like a more powerful version of Awk / Perl

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.

Re: The Prolog Story (2010)

#18
post #3

I recently used prolog for a complicated binary reverse-engineering task: bit packing. Likewise prolog is perfect for compilation. https://savannah.gnu.org/forum/forum.php?forum_id=9203 In fact it's a better prolog, picat, which also allows pretty straightforward statements, like loops, and has solver support. http://picat-lang.org/

A big point of using Prolog for the commercial projects fitting its niche (1) is that it's based on an ISO standard, though, and implementations are (theoretically) interchangeable. To make Prolog programs actually portable across major Prolog implementations, there's been the Prolog Commons initiative for an extended standard predicate lib.

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

[2]: http://www.prolog-commons.org/

Re: The Prolog Story (2010)

#19
post #3

I recently used prolog for a complicated binary reverse-engineering task: bit packing. Likewise prolog is perfect for compilation. https://savannah.gnu.org/forum/forum.php?forum_id=9203 In fact it's a better prolog, picat, which also allows pretty straightforward statements, like loops, and has solver support. http://picat-lang.org/

What types of problems does one use constraint programming for? Large optimization problems require something like CPLEX usually.

Re: The Prolog Story (2010)

#20
post #9

I would like to know what Prolog implementation the author used. In particular, the article claims: 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…

(I am the author.) 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 th…

Hi Kyle, Peter Sherman here. (I posted this HN article). You and I had an email dialogue around 2012, and of course I remember you from your Delphi days (BDE Alternatives Guide, etc.) and the old Joel On Software forum. Anyway, the other day I was reading about CoQ and it's use for formal verification, which turns out to solve problems in various different diverse domains, and I said to myself, "Hey, this sounds a whole heck of a lot like Prolog, plus a type system", and so I was attempting to compare and contrast the two systems when I thought back to your great video detailing the customer problem you had and how you used Prolog to solve it. So, that's why the link appears on HN now, that's why the lag time -- to answer your other question. Hey, if you've got a spare minute or two, you should shoot me an email, peter.d.sherman AT gmail DOT com. I might have an interesting business proposition for you...
Post reply on HN