I've been using Prolog on and off for 20+ years (I actually bought and used Turbo Prolog by Borland under MS-DOS). I have to confess though, I've never quite understood Prolog or what it's for. I've followed Markus Triska and his Power of Prolog videos (watched all of them). I'd like to thank him for his work. This fellow is super smart about programming, and he appears to be singlehandedly re-inventing Prolog. His videos are of the highest quality content. I've learned so much from his work, particularly in the area of CLP. I've now come to understand Prolog as a search language, and he's convinced me that CLP+Prolog are the next generation of Prolog as compelling tool. (I do a bunch of work in personnel scheduling/optimization and have mostly used genetic algorithms to this point. I'm seeing more and more uses of Prolog in this area thanks to Mr. Triska.)
I have studied Prolog from time to time over the years and occasionally I run across problems where it strikes me Prolog would be useful but I've never been able to justify adding it.
Lately I've encountered more offline/batch processing problems and I am planning to work on some reimplementations of my solutions in our usual languages using Prolog (as soon as I have some free time, so none too soon).
Doctor Dobb's Journal had a cool article once about using Prolog to prescribe medications, in particular avoiding conflicts with other prescriptions. It would have been in the early 2000s. According to the author, they used Prolog to rewrite the app from a tangled mess of nested if statements. After the rewrite, the rules could be managed by pharmacists instead of programmers. It seemed like a good application to me. I studied Prolog in college but have never used it professionally. I keep hearing good things about Datalog, which I know even less about. . . .
It hits right at the core of the appeal (these kind of solvers need to be designed, if you grow them organically you get the if statement from hell) and also the challenges (not many managers would run with the idea of "the users will be doing something that looks a lot like writing code").
Prolog is the only language that I've ever learned that feels like magic. Of course, it's not, but it feels like that. I'm still learning it, but I feel it and the logic paradigm are underused. I wonder if it's fair to consider it constraint-based programming rather than just logic programming. I used the book Thinking as Computation to learn it (and still am), and that's what it felt like we were doing in the book: just setting up constraints for the program to run through and find matches for the constraints.
It's criminally underused, and it's a weird blind spot for software developers to have. My input on this is that our primary working tool, a programming language, is so powerful and wide that (within the limits of computability) it can literally do anything; therefore we are less likely to question the paradigm or look for a different one, even when it would be more suited to the problem at hand.
Prolog is a deep language and can teach so you a lot. The main problem is that any prolog program bigger than, say, a thousand lines of code become difficult to debug and understand. There are ways to make things better e.g. avoid impure prolog etc. but it is still problematic.
Engineers are always looking for technologies to hop onto. Prolog is niche for a reason: I don’t think Prolog scales. In some ways it is too flexible and powerful.
On the other hand, with dozens of lines of Prolog you can solve some problems that would take many thousands of lines in other languages (and a lot of calm study before you can map them into a real logic or imperative algorithm).
I still avoid it, because yeah, once you solve that problem and avoid those thousands of lines, you are stuck. If you try make the rest of your system in Prolog, it will become a non-viable mess before you even finish it.
That said, I think the main thing that Prolog is missing is easy integration with other languages. If I could define some environment in Haskell, pack it with some Prolog predicate and get a list back, I would use it all the time.
I think Minikanren does a pretty good job of being an embeddable version of Prolog. It's not that difficult to implement in whatever language you choose and uses the host language's data structures, you just have to implement unification over those days structures (i.e. figure out how to make it a tree). The main things it can't do is function like a database, though even that might be possible if you get creative.
I'm not familiar with Prolog and this statement sounds insane. I'm not doubting you exactly, it's just not something I can concieve. Can you provide an example of a problem that would only take a few dozen lines of Prolog which would take several thousand lines in another, "normal", language?
It's been more than a decade since I worked in Prolog, so I cannot give you a direct example but can try to answer :)
Basically, Prolog is declarative programming. You can attach properties to your data and then define relations between the data based on whether they have that property (or not). Something along the lines of: X is grandfather of Y if X is man and X has child Z which has child Y.
The above statement is very simple to write, a couple of lines. This will perform depth first search (or breadth first with some longer algirithm) using your data. As a result, Prolog can provide all such matches of all your data, or just the grandchildren of X, or both grandfathers of Y, etc.
Anyway, what you are really getting is just a good implementation of the search through the relations based on constraints. The main reason Prolog is used is because other languages just don't provide a good library for constraint based search through your data.
So You are saying that there is really not much difference between prolog and lets say constraint solver written in Java (DSL on top of another language)? Because if this really true than now I understand why this language never caught on.
It depneds on the comment and the article. I actually had some contact with prolog (did a semester in university mamy years ago) and still up till today did not find a reason to use it on real life - mainly because I have responsibily to keep my solutions maintainable for decades and I do not see how could I keep easily find people willing to work on prolog and not switch obver to where reall money is at.
So when I saw an interesting insight that somehow maches my very old intuition (that prolog is mainly constraint solver) I wanted to ask more. And I believe that reading this whole introduction could potentially not give me this insight.
That seems like main reason any high level language exist - to give us abstraction layer with better building blocks to solve problems. The trick is to choose which DSL to use in project so its maintainable (and cost effective). I even long time ago learned some prolog (had a whole semester in university on it) but I cannot find a reason why I would use it anywhere in real projects.
I believe in general purpose languages - from the business point of view its better to invest in one platform/language/ecosystem (if possible of course) than to spread too thin - each specialized language is potential liability (its trade-off but still the additional languages have to carry their own weight allowing for example to access more platforms)
Basically any problem involving a complex search of a solution space is a strong candidate for the above statement. There are specialized tools for doing that in other languages, but a) they specialize on a single optimization/search topic and b) their use is generally quite complex vs. prolog.
Are there any Prolog scripting engines or embeddable runtimes? It feels like the kind of thing where you might use it to solve a small part of your problem domain and leave the rest to a conventional language.
To an extent, you get this with Datalog, which is an easily embeddable subset of pure Prolog.
I've been spending a ton of time with the language and its implementation through my day job, and I recently spoke about its use as a DSL for embedded knowledge bases: https://www.youtube.com/watch?v=lYLkaOq7WbU
May I interest you in microKanren? You can just roll your own. Here’s a shameless self-plug for a close reading I did of the paper that introduces microKanren: https://github.com/ashton314/muKanren_reading
indeed, a LOT of problems boil down to satifiability problems that are super easily expressed in PROLOG. I was recently musing about some of the problems with "automated" ffmpeg processing of obscure files (things like realvideo, etc), because there are a lot of edge cases in terms of filters that can't work on X color space or whatever, and the obvious solution that presented itself was a prolog rules/knowledge base that "understands" the conversion process and finds appropriate filters to put together a chain between some arbitrary input and output tuples.
After some time using it you understand it works for everything. Essentially, it features simpler and powerful loops and recursions. So you wrote those differently and end up writing many things differently.
That said, I used it for a simple game AI at university. My AI was the best of the class and it was something like 30 LOC. I remember thinking I would have spend 5x more time writing the same thing in C instead of 1 hour (plus some tests and play session)
I have not used it for anything outside of learning, yet. I highly recommend the book Thinking as Computation. It's a really excellent introduction to both Prolog and the subject of the title. It presents Prolog solutions to many topics. For example, there's some game solvers, and the Prolog programs basically consist of writing down the rules of the game.
I do have some ideas for some apps I'd like to tackle at some point. Those primarily consist of interacting with system constraints.
Prolog is used A LOT behind the scene for discrete optimization in logistics, finance, and more. See [1] for an introduction going from no prior knowledge to overcoming issues with assertz and co.
I've been using it to try and figure out the longest consecutive bus route journey in London (648-649-651, disappointingly short) and some other bus related shenanigans - all of this was much easier than using pretty much anything else.
But on the other hand, it can be really faffy to figure out why your recursive list printer is failing halfway through and restarting three items back...
This month Prolog is ranked #21 on TIOBE, ahead of Rust (#28) and TypeScript (#43). This probably demonstrates the irrelevance of TIOBE more than it illustrates the relevance of Prolog.
I think people who don't need to use Prolog think of Prolog in a very idealized way, kind of how they think of other "principled" languages like Lisp or Rust. Many years ago, I took a course at Johns Hopkins called Computational Models of Cognition. It was taught partly in SWI-Prolog. We used Prolog as a simple DSL to write little logical programs. It was different, and fun, and kind of confusing.
But as soon as you want to take Prolog beyond elementary classroom use, you will find that it is a language like many others, and needs to expose a world of little QOL details that go beyond the elegant simplicity of term unification, like argument mode modifiers and continuations and such.
Contrary to what many geeks think, TIOBE is very relevant, because it is where management looks into when discussing which languages get greenlighted to IT.
The way they get those numbers might seem irrelevant, or even unrealistic, yet that doens't change how many companies select the golden languages for their cogs.
I have only had passing experience with Prolog, many moons ago. It feels like ... and this is hard to express without sounding like I am trivializing it ... it feels like Prolog has a pretty good future as domain-specific language as input to a library called by, well, other programming languages, but on its own, it's a "wow, that's neat" kind of language.
This is one of the best resources for learning modern Prolog. It mainly uses Scryer Prolog, which is a still-in-progress open source Prolog system, but very promising and adheres to the ISO standard.
I was expecting a comment like this and came looking... Can someone give a couple of examples of Prolog resembling a database query language, specifically SQL if possible.
Trying not to sound contentious, but I've often thought that SQL (DDLs/DMLs/DQLs) would be a really good way to interact with systems beyond just databases/datastores. And the general tone of this topic has been about how Prolog can solve/simplify so many problems/issues. Relating some Prolog to some SQL might help me (and others) see this light that everyone seems to be talking about.
There has recently been a lot of working examples of SQL being used beyond databases; IaSQL (Infrastructure-as-SQL), KSQL (streaming SQL), so on.
I found that Prolog is excellent for one-shot solving perfectly well-defined Platonic problems. The moment there is some uncertainty, rough edges, user input, etc it becomes nasty. Is this your experience? Am I doing something wrong?
I dusted off an implementation of MQTT for SWI-Prolog so the way I did all the integration was via MQTT messages between Java. Python, c/c++ (on Arduino devices), and Prolog.
These days SWI-Prolog even has a library for Redis.
Does anyone know if Prolog has been used in video games? I keep wondering if complex histories like those in Dwarf Fortress are coded via a Prolog-like approach to keep them consistent and correct.
Isn't RETE a forward-chaining algorithm while Prolog is a backward-chaining language? I'm not sure you could use RETE for the actual Prolog semantics. Currently, fast implementations of Prolog use a virtual machine, the most popular is WAM, that can be compiled then to machine code (GNU Prolog does it). Also some implementations have JIT indexing, which improves performance too.
See the "Typing" section of https://sforman.srht.site/PLSemProlog.html
Note that there's no implementation of the type inference algorithm, just descriptions of the type relations. That's because Prolog itself is the type inference algorithm.
