Is there a reason why anyone would choose prolog today instead of a library? Like racklog [https://docs.racket-lang.org/racklog/]. All the benefits of prolog, with none of the cost of using a new language and integrating it into your project.
Prolog is fun. It's fantastically fun. It's maybe one of the most fun programming languages in existence.
I suppose most people who, in production, have to solve the sort of problems that Prolog is really good at are using some sort of logic programming library (or, more realistically, are implementing their own ad hoc, informally-specified, bug-ridden, slow implementation of half of Prolog). I don't think Prolog is a great language for shipping an actual product. But for me the alternatives are just not as satisfying. Choosing Prolog for a random little personal project (that fits what Prolog wants to do) is a good time.
I think you have a point, but not sure your example illustrates it very well - is Racket really any less niche than Prolog? On the contrary, I would say.
But regardless, if one needs some of the basic features of Prolog and a good library exists for your language/environment of choice (core.logic for Clojure is probably one of the most solid ones at the moment), then I think it's good common sense not to add one more language to your system (assuming this is in a production context, of course). But modern Prolog systems have a lot more functionality than the unification and backtracking semantics that at the core of Prolog. Among them are the constraint solving capabilities that The Power of Prolog describe, and tabling in some form, which allows for efficient execution of programs that in early Prolog systems would lead to non-terminating search.
Not only are these features available, but in many cases they are tightly integrated with the language, optimized and fine-tuned over many years. So the answer is similar to if someone asks "Why choose Erlang when there are actor-based concurrency libraries in so many languages?" (or any number of similar questions): it might not make sense for the simpler use cases, but you won't get the full experience unless you take the plunge.
I was using racklog as an example of a library you would use if your app was programmed in Racket; I wasn't suggesting that you would decide to use racklog in a C project or something over prolog.
I use it. Not regularly, not for production, but it's cute for rapid prototyping.
Last time I had to write a rule-learning-inspired [1] algorithm with a custom hypothesis language. Prolog has the advantage that you can experiment with different search strategies (depth-first search, breadth-first search, informed search, ...) very quickly. Also, given that SWI Prolog can be used without a build system, it is as quick to bootstrap as to write a BASH script. Not even unit tests need a library nor dependencies...
So my use-case for Prolog is:
- prototyping,
- that involves some kind of searching,
- first-order logic, or at least some kind of pattern matching involved and
- no fancy I/O (parsing binary data), because this is IMHO Prolog's weak point.
This is an interesting question, and I hope someone with experiences on both sides could chime in. I would expect an prolog-like implementation in any mature language a possibility and retain language native syntax while garnering all the advantages of prolog.
One of the advantages of Prolog is that there is an ISO standard for it: The standard prescribes, in many ways, which syntax is acceptable, which errors must be generated in which cases, and which results must be produced.
The standard ensures portability of Prolog programs between conforming systems, and significantly simplifies legal disputes in case a system does not conform.
As I see it, this is one of the advantages one loses when using a Prolog-like implementation as opposed to an actual Prolog system, and especially in commercial settings, this may be a significant drawback of using libraries that lack the strong formal backing and guarantees that an ISO standard ensures.
Other advantages of using an actual Prolog system are speed and reliabiliy, and dedicated features such as constraints and built-in grammar mechanisms (DCGs). The availability of expressive and efficient constraints is often an important reason for buying and using a commercial Prolog system. Another important reason is that Prolog syntax and semantics enable declarative debugging approaches such as failure slicing and selective reading. These approaches may not translate to libraries, and also not to other syntactic formalisms.
