The idea at work here is Alan Kay's, to bring the spec into the language as code somehow. Prolog is better suited to this than many other languages, simply because it is so easy to reuse existing operators and structures but overlay them with new semantics, as well as adding your own operators. But I think you can do that same fundamental idea in any language. The ROI will often be lower though, if you tried to do what I did in Java, for instance. In this case the core is very procedural. That was kind of fun to do, just as a reminder that Prolog can do that without it being onerous. But the ROI would have been even higher if the core problem involved nondeterminism, constraints or deduction in some unavoidable way.

A lot of the code I write in Prolog is written to demonstrate you can do practical things in Prolog without it turning into C or Pascal. I feel that Lisp managed to shed the "this is only for AI" stigma, thanks to books like Practical Common Lisp and partly thanks to Emacs itself. But Prolog is still sort of thought of as this freak language only really useful for solving Einstein puzzles and sudoku.

Prolog is not my strongest language, and I am far from an expert in it. But, I don't think you have to be an expert in it to use it productively and enjoy it. If I had tried to do this problem in Haskell or Python or Java, I would probably have solved it in a completely different way.

I don't know if this addresses your questions or not, but I'm glad to talk more.