The Prolog Story (2010)
kylecordes.com
The Prolog Story (2010)
1–10 of 31 posts
Re: The Prolog Story (2010)
#2Previous discussion from 2010: https://news.ycombinator.com/item?id=1363680 (60 comments)
Re: The Prolog Story (2010)
#3I 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.
Re: The Prolog Story (2010)
#4I 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/
Wow, thanks for sharing!
Re: The Prolog Story (2010)
#5I have used Lisp languages far more often than Prolog, but I do have my own Prolog success story: I had just used ExperLisp on the Macintosh to write a little app ExperOPS5 for the company who wrote and marketed ExperLisp and ExperProlog. After this I was given an internal research grant to write a complete simulation environment in ExperLisp as part of trying to win a large contract. Given familiarity with the tools I was using, a good prototype took about 100 hours to write. I had time left over and talked with my management about doing a parallel implementation in ExperProlog. Using a declarative approach, I had a parallel system, with interactive UI and graphics done in about 40 hours - and I had a learning curve with ExperProlog.
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.
Re: The Prolog Story (2010)
#6I 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/
I agree with the other commenter’s Wow! Picat also supports satisfiability apps like MiniZinc does. Thanks for posting that link!
Re: The Prolog Story (2010)
#7I 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/
I agree with the other commenter’s Wow! Picat also supports satisfiability apps like MiniZinc does. Thanks for posting that link!
Initially I choose MiniZinc, but then was turned off by its baroque syntax. Straight prolog syntax and picat syntax was much easier in the end.
writing prolog is mostly about writing in the most natural and readable syntax possible. using haskell-like types put me off.
Re: The Prolog Story (2010)
#8Prolog 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.
Re: The Prolog Story (2010)
#9I 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 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?
Re: The Prolog Story (2010)
#10I 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…
On rereading, it seems like what may be happening is simply that the problem isn't very large (10-100,000 rows) and doesn't need to be solved very fast (a few minutes), and so the standard Prolog search strategy may have worked just fine. A good example of avoiding unnecessary over-engineering.
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.