Prolog Coding Horror

A few years ago I wrote a workforce scheduling program designed to be used by non-programmers. I worked in a restricted environment so couldn't install anything. The whole thing ran on SWIPL's web offering.

Users simply had to change the basic "facts" (who was available on what days, how many people were needed), and the program solved for the various constraints and offered solutions.

It was maybe about 300 lines of Prolog, no complex dependencies. It replaced a pile of Python scripts that required a lot of state, didn't really work, and could only run on a few specific computers.

For regular users, it was relatively easy to understand and change the facts. SWIPL for web also offers a nice "notebook" interface that lets you mix data, code, and markdown / output blocks so the documentation was inline.

I used Prolog twice in production, but none of them were what I'd expect to be the "typical" uses.

1. I used GoLog (a Prolog interpreted in Go) for defining some functional tests in the project where the testing infrastructure was otherwise written in Go.

2. I used Prolog (SWI) to write a parser for Thrift (both the definition and binary format) simply because I needed one, and Prolog was convenient.

What I expect people who use Prolog for the stuff it's really good at is databases that encode some complicated business or legal processes. I.e. databases with many complex constraints that have to all somehow come together to produce a solution set. Prolog would also be a good language to encode / query graph databases. So, whatever you can think of being a good match for a graph database would also work well with Prolog.

There are also (even more niche) Prolog derivatives, eg. Ciao or Mercury, that are... well, decent all-purpose languages. You can just use them in the same context where you'd use Python or Haskell respectively. The implementations are pretty solid in terms of performance and correctness... so, if you like the approach, then why not?

You could always read the docs?

https://www.swi-prolog.org/pldoc/man?section=clpfd-integer-a...

https://www.swi-prolog.org/pldoc/doc_for?object=!/0

"Planning, optimization, diagnostics, and complex configuration" [1]

Prolog also works extremely well as a target language for code generation by LLMs for these domains due to it being "higher up in the food chain" compared to procedural languages so to speak, and because Prolog was originally envisioned for classic NLP and hence has a corpus of one-to-one mappings from natural language to logic (as in the example in [3]). So well in fact that even with last-gen models textual descriptions for suitable problems become the bottleneck and you can in many cases just go straight to Prolog code instead ([2]).

[1]: https://quantumprolog.sgml.net

[2]: https://quantumprolog.sgml.net/llm-demo/part1.html

[3]: https://news.ycombinator.com/item?id=48080201

Not familiar with Erlang that much, but it's pretty clear Erlang was prototyped on Prolog because of its convenient facilities for DSLs using op/3 to define new tokens for its built-in bottom-up expression parser (using operator precedence parsing) and its Definite Clause Grammar recursive descent parser as trivial specialization of core SLD resolution (Prolog was created for NLP and planning apps in the first place after all).

I guess what may also have contributed is that there are a number of concurrent logics implemented in Prolog for prototyping Erlang's scheduler such as Concurrent Transaction Logic ([1]).

[1]: https://www.cs.toronto.edu/~bonner/ctr/Home.html