triska

> "a few degrees, what difference does that make?"

Maybe this helps: Think about when we have a fever of "a few degrees", say, instead of 37 degree Celsius, we have 40. It shows that also a few degrees can make a huge difference.

Thank you a lot for your interest! Yes of course: As I see it, Prolog is often awesome in types of applications that are distinct from those one would usually build in other kinds of languages.

Alex Petros phrased it extremely nicely and insightfully in his comment at https://lobste.rs/s/0cvxwk/prolog_basics_explained_with_poke...:

"I don't know if this will be a satisfying answer to your question, but since writing this blog post I find myself reaching for Prolog in cases that are entirely orthogonal to any kind of code I used to write before. There are definitely people in the Prolog community who like using it for web servers or whatnot, but for me personally it's more about unlocking a different skill tree. For instance, I've become better at identifying where custom parsers or DSLs might be a good fit for a problem."

The mentioned blog post by Alex is available from: https://unplannedobsolescence.com/blog/prolog-basics-pokemon... and was recently discussed here: https://news.ycombinator.com/item?id=48147091

For another example, please see factgraph.pl also by Alex: https://github.com/alexpetros/factgraph.pl

Prolog is great in applications that must be able to analyze, extend, adapt, reason about and give account of their own workings and results. As an example for this, please see An Executable Specification of Oncology Dose-Escalation Protocols with Prolog by David C. Norris and me: https://arxiv.org/abs/2402.08334

In this example and others like it, one of the things the formulation is able to do is to tell us what the next step should be. And far, far beyond that, the same formulation can be used in many other ways, for instance to enumerate all cases that can arise, or to complete partially known cases, or to retroactively answer questions such as "Was the trial performed according to protocol?" We say we can use a logic program in different modes. And further, since a Prolog program is a sequence of Prolog terms, we can also use Prolog to easily read and analyze the formulation, and verify correctness or optimality properties of the formulation. Further, we can apply different execution strategies, including strategies that keep track of the reasons why specific results arose, and thus also produce automatic explanations of computed results.

Awesome work, thank you a lot Javier for making this available, and for the Scryer Prolog improvements that make this possible!

I see that almost all of the changes mentioned on the page are in fact already filed for inclusion:

https://github.com/mthom/scryer-prolog/pull/3379

https://github.com/mthom/scryer-prolog/pull/3383

https://github.com/mthom/scryer-prolog/pull/3387

https://github.com/mthom/scryer-prolog/pull/3390

If anyone is interested in contributing to Scryer Prolog and getting these changes included, please have a look and participate in the accompanying discussions, thank you a lot!

For everyone interested in Prolog and its applications, please also consider attending the Scryer Prolog Meetup 2026 on Oct. 24th and 25th in Vienna:

https://www.digitalaustria.gv.at/wissenswertes/events/scryer...

I hope to see several of you there!

I think this is very well phrased, and I would argue the same holds for Prolog too.

In my opinion, a key difference between Prolog and other languages in that regard is one of degree, not kind: Compared to other languages, addressing performance problems in Prolog engines tends to have far greater effects on Prolog programs, because so much is implicit (i.e., left to the engine).

If the performance problem is not in the engine, but in the program itself, then we will face the same questions with Prolog as with other languages: How to formulate the program better, is there a better approach altogether?

For example, earlier today an interesting question regarding performance was posted in the Scryer discussions:

https://github.com/mthom/scryer-prolog/discussions/3341

The comparison in this case is between Gecode and Scryer on a seemingly simple but nontrivial combinatorial task. What is the problem here? Most likely the Scryer engine itself can be improved. And also very likely, there are better ways to model the task, and also better search strategies, and these tend to have far greater performance impact than the base language, and these questions remain also if we change the base language.

In my opinion, these questions regarding different kinds of formulations tend to be more frequently associated with Prolog than with other languages because Prolog is more frequently used for complex tasks where it is not a priori clear how to even approach the problem.

How is this different from other programming languages though?

One example I often think about is from Ken Silverman: "sub eax, 128" → "add eax, -128". So equivalent ways to write the same program may have different performance characteristics also depending on the tools that are applied. How many people could tell without trying which way to write this example is preferable?

The same phenomenon will be encountered in all kinds of languages, where engine and compiler improvements make existing code faster or slower.

Regarding distributed systems, I find Torbjörn Lager's recent work on Web Prolog particularly interesting. He recently posted about it here:

https://github.com/mthom/scryer-prolog/discussions/3322

and also in the course of a discussion on various approaches to implement concurrency in Prolog:

https://github.com/mthom/scryer-prolog/discussions/3307

Very nice!

In the Scryer Prolog discussions, Alex has shared a few ideas and considerations for possible improvements to the Prolog code, including the use of metaprogramming to automatically generate more general relations:

https://github.com/mthom/scryer-prolog/discussions/3221

I hope for an interesting followup article!

Another very interesting Prolog program by Alex is factgraph.pl:

https://github.com/alexpetros/factgraph.pl

It's a Prolog implementation of the IRS Fact Graph, an application of Law as Code.

Quoting from the Charter of Fundamental Rights of the European Union, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:12... :

"Article 7

Respect for private and family life

Everyone has the right to respect for his or her private and family life, home and communications.

Article 8

Protection of personal data

1. Everyone has the right to the protection of personal data concerning him or her.

2. Such data must be processed fairly for specified purposes and on the basis of the consent of the person concerned or some other legitimate basis laid down by law. Everyone has the right of access to data which has been collected concerning him or her, and the right to have it rectified.

3. Compliance with these rules shall be subject to control by an independent authority."