There wasn't a lot of literature on it or implementations then but a few years later people realized it's a great query language for complex queries that does a great job on transitive closures, can do math (unlike OWL which won't do it because Gödel proved first order logic + math is a hot mess)
I took a comparative programming languages course circa 1993, the instructor thought that that Prolog was a taste of the future of programming. At first I thought the way you can implement ordinary procedural code in Prolog was really clever but if you write very much of it I think it is awkward; for instance it is common to treat procedural success as a logical failure because that gets the behavior you want.
It's counterintuitive that you could write a reasonably fast interpreter for Prolog but Warren figured out how to do it and it really is a neat trick. In the 1980s the Japanese Fifth Generation project dreamed about parallel Prolog on a machine with 100s of CPUs but it was discovered pretty quickly that you couldn't really parallelize Prolog execution so they came up with the less expressive language
I am amused to see papers today where people are working on tasks similar to what they worked on in that project, parallelizing them with commodity hardware, and get scaling curves that look very similar to what was done with KL1. (In the end the 5GP settled on the same message-passing architecture that everybody else did until the GPU revolution came)
One of the nicest examples in Prolog is writing a parser by just writing the productions which works because Prolog's resolver is quite similar to a common parsing algorithm. In the large however, you can add a library to a normal programming language like Python or Java where you write the same grammar in a DSL and it is handled by the library.
See also production rules systems which use "forward chaining" with the RETE algorithm and variants for an approach which looks like Prolog in some ways but works in the reverse direction. My favorite example of this now is
I built a prototype of a stream processing engine where the control plane was implemented as a set of production rules that would build a processing pipeline of reactive operators, key-value and triple stores and then tear it down. Unlike another stream processing engine I worked on, mine always got the right answers. I think a production rule system could be the target of a "low code" system. I'm a little disappointed that I've never seen a Javascript framework that uses production rules because they are a great answer to asynchronous communication choreography. (See complex event processing)
There was a massive parallel implementation of Prolog running on literally 256 processors: BA-Prolog (http://fraber.de/bap/). Unfortunately the hardware platform was abandoned some years later by Inmos.
In the 2000s I was interested in inference over RDF and wanted something a bit more than RDFS and OWL and found out about Datalog:
https://en.wikipedia.org/wiki/Datalog
There wasn't a lot of literature on it or implementations then but a few years later people realized it's a great query language for complex queries that does a great job on transitive closures, can do math (unlike OWL which won't do it because Gödel proved first order logic + math is a hot mess)
I took a comparative programming languages course circa 1993, the instructor thought that that Prolog was a taste of the future of programming. At first I thought the way you can implement ordinary procedural code in Prolog was really clever but if you write very much of it I think it is awkward; for instance it is common to treat procedural success as a logical failure because that gets the behavior you want.
It's counterintuitive that you could write a reasonably fast interpreter for Prolog but Warren figured out how to do it and it really is a neat trick. In the 1980s the Japanese Fifth Generation project dreamed about parallel Prolog on a machine with 100s of CPUs but it was discovered pretty quickly that you couldn't really parallelize Prolog execution so they came up with the less expressive language
https://en.wikipedia.org/wiki/KL1
I am amused to see papers today where people are working on tasks similar to what they worked on in that project, parallelizing them with commodity hardware, and get scaling curves that look very similar to what was done with KL1. (In the end the 5GP settled on the same message-passing architecture that everybody else did until the GPU revolution came)
One of the nicest examples in Prolog is writing a parser by just writing the productions which works because Prolog's resolver is quite similar to a common parsing algorithm. In the large however, you can add a library to a normal programming language like Python or Java where you write the same grammar in a DSL and it is handled by the library.
See also production rules systems which use "forward chaining" with the RETE algorithm and variants for an approach which looks like Prolog in some ways but works in the reverse direction. My favorite example of this now is
http://www.clara-rules.org/
I built a prototype of a stream processing engine where the control plane was implemented as a set of production rules that would build a processing pipeline of reactive operators, key-value and triple stores and then tear it down. Unlike another stream processing engine I worked on, mine always got the right answers. I think a production rule system could be the target of a "low code" system. I'm a little disappointed that I've never seen a Javascript framework that uses production rules because they are a great answer to asynchronous communication choreography. (See complex event processing)