> "4. Prolog is good at solving reasoning problems."
Plain Prolog's way of solving reasoning problems is effectively:
for person in [martha, brian, sarah, tyrone]:
if timmy.parent == person:
print "solved!"
You hard code some options, write a logical condition with placeholders, and Prolog brute-forces every option in every placeholder. It doesn't do reasoning.
Arguably it lets a human express reasoning problems better than other languages by letting you write high level code in a declarative way, instead of allocating memory and choosing data types and initializing linked lists and so on, so you can focus on the reasoning, but that is no benefit to an LLM which can output any language as easily as any other. And that might have been nice compared to Pascal in 1975, it's not so different to modern garbage collected high level scripting languages. Arguably Python or JavaScript will benefit an LLM most because there are so many training examples inside it, compared to almost any other langauge.
Even in your example (which is obviously not correct representation of prolog), that code will work X orders magnitude faster and with 100% reliability compared to much more inferior LLM reasoning capabilities.
Algorithmically there's nothing wrong with using BFS/DFS to do reasoning as long as the logic is correct and the search space is constrained sufficiently. The hard part has always been doing the constraining, which LLMs seem to be rather good at.
Of course it does "reasoning", what do you think reasoning is? From a quick google: "the action of thinking about something in a logical, sensible way". Prolog searches through a space of logical proposition (constraints) and finds conditions that lead to solutions (if one exists).
(a) Trying adding another 100 or 1000 interlocking proposition to your problem. It will find solutions or tell you one doesn't exist.
(b) You can verify the solutions yourself. You don't get that with imperative descriptions of problems.
(b) Good luck sandboxing Python or JavaScript with the treat of prompt injection still unsolved.
As someone who did deep learning research 2017-2023, I agree. "Neurosymbolic AI" seems very obvious, but funding has just been getting tighter and more restrictive towards the direction of figuring out things that can be done with LLMs. It's like we collectively forgot that there's more than just txt2txt in the world.
I am once again shilling the idea that someone should find a way to glue Prolog and LLMs together for better reasoning agents.
There are definitely people researching ideas here. For my own part, I've been doing a lot of work with Jason[1], a very Prolog like logic language / agent environment with an eye towards how to integrate that with LLMs (and "other").
Nothing specific / exciting to share yet, but just thought I'd point out that there are people out there who see potential value in this sort of thing and are investigating it.
We've done this, and it works. Our setup is to have some agents that synthesize Prolog and other types of symbolic and/or probabilistic models. We then use these models to increase our confidence in LLM reasoning and iterate if there is some mismatch. Making synthesis work reliably on a massive set of queries is tricky, though.
Imagine a medical doctor or a lawyer. At the end of the day, their entire reasoning process can be abstracted into some probabilistic logic program which they synthesize on-the-fly using prior knowledge, access to their domain-specific literature, and observed case evidence.
There is a growing body of publications exploring various aspects of synthesis, e.g. references included in [1] are a good starting point.
It's been a while since I have done web dev, but web devs back then were certainly not scared of any language. Web devs are like the ultimate polyglots. Or at least they were. I was regularly bouncing around between a half dozen languages when I was doing pro web dev. It was web devs who popularized numerous different languages to begin with simply because delivering apps through a browser allowed us a wide variety of options.
Can't find the links right now, but there were some papers on llm generating prolog facts and queries to ground the reasoning part. Somebody else might have them around.
There's a lot of work in this area. See e.g., the LoRP paper by Di et al. There's also a decent amount of work on the other side too, i.e., using LLMs to convert Prolog reasoning chains back into natural language.
IIRC IBM’s Watson (the one that played Jeopardy) used primitive NLP (imagine!) to form a tree of factual relations and then passed this tree to construct Prolog queries that would produce an answer to a question. One could imagine that by swapping out the NLP part with an LLM, the model would have 1. a more thorough factual basis against which to write Prolog queries and 2. a better understanding of the queries it should write to get at answers (for instance, it may exploit more tenuous relations between facts than primitive NLP).
YES! I've run a few experiments on classical logic problems and an LLM can spit out Prolog programs to solve the puzzel. Try it yourself, ask an LLM to write some prolog to solve some problem and then copy paste it to https://swish.swi-prolog.org/ and see if it runs.
Prolog really is such a fantastic system, if I can justify its usage then I won't hesitate to do so. Most of the time I'll call a language that I find to be powerful a "power tool", but that doesn't apply here. Prolog is beyond a power tool. A one-off bit of experimental tech built by the greatest minds of a forgotten generation. You'd it find deep in irradiated ruins of a dead city, buried far underground in a bunker easily missed. A supercomputer with the REPL's cursor flickering away in monochrome phosphor. It's sitting there, forgotten. Dutifully waiting for you to jack in.
When I entered university for my Bachelors, I was 28 years old and already worked for 5 or 6 years as a self-taught programmer in the industry. In the first semester, we had a Logic Programming class and it was solely taught in Prolog.
At first, I was mega overwhelmed. It was so different than anything I did before and I had to unlearn a lot of things that I was used to in "regular" programming. At the end of the class, I was a convert! It also opened up my mind to functional programming and mathematical/logical thinking in general.
I still think that Prolog should be mandatory for every programmer. It opens up the mind in such a logical way... Love it.
Unfortunately, I never found an opportunity in my 11 years since then to use it in my professional practice. Or maybe I just missed the opportunities?????
Did they teach you how to use DCGs? A few months ago I used EDCGs as part of a de-spaghettification and bug fixing effort to trawl a really nasty 10k loc sepples compilation unit and generate tags for different parts of it. Think ending up with a couple thousand ground terms like:
tag(TypeOfTag, ParentFunction, Line).
Type of tag indicating things like an unnecessary function call, unidiomatic conditional, etc.
I then used the REPL to pull things apart, wrote some manual notes, and then consulted my complete knowledgebase to create an action plan. Pretty classical expert system stuff. Originally I was expecting the bug fixing effort to take a couple of months. 10 days of Prolog code + 2 days of Prolog interaction + 3 days of sepples weedwacking and adjusting the what remained in the plugboard.
But some parts, like e.g. the cut operator is something I've copied several times over for various things. A couple of prototype parser generators for example - allowing backtracking, but using a cut to indicate when backtracking is an error can be quite helpful.
I remember a project I did in undergrad with Prolog that would fit connecting parts of theoretical widgets together based on constraints about how different pieces could connect and it just worked instantly and it felt like magic because I had absolutely no clue how I would have coded that in Pascal or COBOL at that time. It blew my mind because the program was so simple.
I've recently started modeling some of my domains/potential code designs in Prolog. I'm not that advanced. I don't really know Prolog that well. But even just using a couple basic prolog patterns to implement a working spec in the 'prolog way' is *unbelievably* useful for shipping really clean code designs to replace hoary old chestnut code. (prolog -> ruby)
I keep wishing for "regex for prolog", ie: being able to (in an arbitrary language) express some functional bits in "prolog-ish", and then be able to ask/query against it.
let prologBlob = new ProLog()
prologBlob.add( "a => b" ).add( "b => c" )
prologBlob.query( "a == c?" ) == True
(not exactly that, but hopefully you get the gist)
There's so much stuff regarding constraints, access control, relationship queries that could be expressed "simply" in prolog and being able to extract out those interior buts for further use in your more traditional programming language would be really helpful! (...at least in my imagination ;-)
While usually using native syntax rather than strings, somethign like that exists for most languages of any popularity (and many obscure ones), in the form of miniKanren implementations.
If you really want something that takes Prolog strings instead (and want the full power of prolog), then there are bindings to prolog interpreters from many languages, and also SWI-Prolog specifically provides a fairly straightforward JSON-based server mode "Machine Query Interface" that should be fairly simple to interface with any language.
I've wished for the same kind of 'embed prolog in my ruby' for enumerating all possible cases, all invalid cases, etc in test suites. Interesting to know it's not just me!
I did try ruby-prolog. The deeper issue is that its just not prolog. Writing in actual prolog affords a lot of clarity and concision which would be quite noisy in ruby-prolog. To me, the difference was stark enough it wasn't worth any convenience already being in ruby was worth.
I studied prolog back in 2014. It was used in AI course. I found it very confusing: trying to code A*, N-Queens, or anything in it was just too much.
Python, in contrast, was a god-send.
I failed the subject twice in my MSc (luckily passing the MSc was based on the total average), but did a similar course in UC Berkeley, with python: aced it, loved it, and learned a lot.
A similar thing happened at my university in an Advanced Algorithms course. Students failed it so much, the university was forced to make the course easier to pass, by removing the minimum grade to pass.
I believe your case (and many other students) is that you couldn't abstract yourself from imperative programming (python) into logic programming (prolog).
I remember writing a Prolog(ish) interpreter in Common Lisp in an 90's AI course in grad school for Theorem proving (which is essentially what Prolog is doing under the hood). Really foundational to my understanding of how declarative programming works. In an ideal world I would still be programming in Lisp and using Prolog tools.
I can tell you, from the year 2045, that running the worlds global economy on Javascript was the direct link to the annihilation of most of our freedom and existence. Hope this helps.
Speaking as someone who just started exploring Prolog and lisp, and ended up in the frozen north isolated from internet - access. The tools were initially locked/commercial only during a critical period, and then everyone was oriented around GUIs - and GUI environments were very hostile to the historical tools, and thus provided a different kind of access barrier.
A side one is that the LISP ecology in the 80s was hostile to "working well with others" and wanted to have their entire ecosystem in their own image files. (which, btw, is one of the same reasons I'm wary of Rust cough)
Really, it's only become open once more with the rise of WASM, systemic efficiency of computers, and open source tools finally being pretty solid.
Declarative languages are fantastic to reason about code.
But the true power is unlocked once the underlying libraries are implemented in a way that surpassesthe performance that a human can achieve.
Since implementation details are hidden, caches and parallelism can be added without the programmer noticing anything else than a performance increase.
This is why SQL has received a boost the last decade with massively parallel implementations such as BigQuery, Trino and to some extent DuckDB. And what about adding a CUDA backend?
But all this comes at a cost and needs to be planned so it is only used when needed.
I love Prolog, and have seen so many interesting use cases for it.
In the end though, it mostly just feels enough of a separate universe to any other language or ecosystem I'm using for projects that there's a clear threshold for bringing it in.
If there was a really strong prolog implementation with a great community and ecosystem around, in say Python or Go, that would be killer. I know there are some implementations, but the ones I've looked into seem to be either not very full-blown in their Prolog support, or have close to non-existent usage.
Python wins out in the versatility conversation because of its ecosystem, I'm still kinda convinced that the language itself is mid.
Prolog has many implementations and you don't have the same wealth of libraries, but yes, it's Turing complete and not of the "Turing tarpit" variety, you could reasonably write entire applications in SWI-Prolog.
Right, Python is usually the second-best choice for a language for any problem --- arguably the one thing it is best at is learning to program (in Python) --- it wins based on ease-of-learning/familiarity/widespread usage/library availability.
Personally I find Python more towards the bottom of the list with me, despite being the language I learned on. Especially if the code involved is "pythonic". Just doesn't jive with my neurochemistry. All the problems of C++ with much greater ambiguity, and I've never really been impressed with the library ecosystem. Yeah there's a lot, but just like with node it's just a mountain of unusably bad crap.
I think lua is the much better language for a wide variety of reasons (Most of the good Python libraries are just wrappers around C libraries, which is necessary because Python's FFI is really substandard), but I wouldn't reach for python or lua if I'm expecting to write more than 1000 lines of code. They both scale horribly.
I don't know if I would say its second-best. It just happened to get really popular because it has relatively easy syntax, and Numpy is a really great library making all of those scientific packages that people were using Fortran and C++ for before available in an easier language. This boosted the language, right when data science became a thing, right when dynamic programming became popular, right when there was a boost in Learn 2 Code forget about learning fundamentals was a thing. Its an okay language I guess, but I really think it was lucky that Numpy exists and Numby or Numphp.
In theory, it's as versatile as Python et al[0] but if you're using it for, e.g., serving bog-standard static pages over HTTP, you're very much using an industrial power hammer to apply screws to glass - you can probably make it work but people will look at you funny.
[0] Modulo that Python et al almost certainly have order(s) of magnitude more external libraries etc.
FWIK; You can't compare the two. Python is far more general and larger than Prolog which is more specialized. However there have been various extensions to Prolog to make it more general. See Extensions section in Prolog wikipedia page - https://en.wikipedia.org/wiki/Prolog#Extensions Eg. Prolog++ - https://en.wikipedia.org/wiki/Prolog%2B%2B to allow one to do large-scale OO programming with Prolog.
Earlier, Prolog was used in AI/Expert Systems domains. Interestingly it was also used to model Requirements/Structured Analysis/Structured Design and in Prototyping. These usages seems interesting to me since there might be a way to use these techniques today with LLMs to have them generate "correct" code/answers.
Do you mean Northern Conservative Baptist Great Lakes Region Council of 1879 standard Prolog?[2]
SWI Prolog (specifically, see [2] again) is a high level interpreted language implemented in C, with an FFI to use libraries written in C[1], shipping with a standard library for HTTP, threading, ODBC, desktop GUI, and so on. In that sense it's very close to Python. You can do everyday ordinary things with it, like compute stuff, take input and output, serve HTML pages, process data. It starts up quickly, and is decently performant within its peers of high level GC languages - not v8 fast but not classic Java sluggish.
In other senses, it's not. The normal Algol-derivative things you are used to (arithmetic, text, loops) are clunky and weird. It's got the same problem as other declarative languages - writing what you want is not as easy as it seemed like it was going to be, and performance involves contorting your code into forms that the interpreter/compiler is good with.
It's got the problems of functional languages - everything must be recursion. Having to pass the whole world state in and out of things. Immutable variables and datastructures are not great for performance. Not great for naming either, temporary variable names all over.
It's got some features I've never seen in other languages - the way the constraint logic engine just works with normal variables is cool. Code-is-data-is-code is cool. Code/data is metaprogrammable in a LISP macro sort of way. New operators are just another predicate. Declarative Grammars are pretty unique.
The way the interpreter will try to find any valid path through your code - the thing which makes it so great for "write a little code, find a solution" - makes it tough to debug why things aren't working. And hard to name things, code doesn't do things it describes the relation of states to each other. That's hard to name on its own, but it's worse when you have to pass the world state and the temporary state through a load of recursive calls and try to name that clearly, too.
It's a recursive countdown. There's no deliberate typos in it, but it won't work. The reason why is subtle - that code is doing something you can't do as easily in Python. It's passing a Prolog source code expression of X-1 into the recursive call, not the result of evaluating X-1 at runtime. That's how easy metaprogramming and code-generation is! That's why it's a fun language! That's also how easy it is to trip over "the basics" you expect from other languages.
It's full of legacy, even more than Python is. It has a global state - the Prolog database - but it's shunned. It has two or three different ways of thinking about strings, and it has atoms. ISO Prolog doesn't have modules, but different implementations of Prolog do have different implementations of modules. Literals for hashtables are contentious (see [2] again). Same for object orientation, standard library predicates, and more.
Prolog is easily one of my favorite languages, and as many others in this thread, I first encountered it during university. I ended up teaching it for a couple of years (along with Haskell) and ever since, I've gone on an involuntary prolog bender of sorts once or twice a year. I almost always use it for Advent of code as well.
There seems to an interesting difference between Prolog and conventional (predicate) logic.
In Prolog, anything that can't be inferred from the knowledge base is false. If nothing about "playsAirGuitar(mia)" is implied by the knowledge base, it's false. All the facts are assumed to be given; therefore, if something isn't given, it must be false.
Predicate logic is the opposite: If I can't infer anything about "playsAirGuitar(mia)" from my axioms, it might be true or false. It's truth value is unknown. It's true in some model of the axioms, and false in others. The statement is independent of the axioms.
Deductive logic assumes an open universe, Prolog a closed universe.
I really enjoyed learning Prolog in university, but it is a weird language. I think that 98% of tasks I would not want to use Prolog for, but for that remaining 2% of tasks it's extremely well suited for. I have always wished that I could easily call Prolog easily from other languages when it suited the use case, however good luck getting most companies to allow writing some code in Prolog.
That is where Lisp or Scheme weirdly shines. It is incredibly easy to add prolog to a Lisp or a Scheme. It’s almost as if it comes out naturally if you just go down the rabbit hole.
“The little prover” is a fantastic book for that. The whole series is.
One can of course add the same stuff to other languages in form of libraries and stuff, but lisp/scheme make it incredibly easy to make it look like part of the language itself and make seem a mere extension of the language. So you can have both worlds if you want to. Lisp/scheme is not dead.
In fact, in recent years people have started contributing again and are rediscovering the merits.
Racket really shines in this regard: Racket makes it easy to build little DSLs, but they all play perfectly together because the underlying data model is the same. Example from the Racket home page: https://racket-lang.org/#any-syntax
You can have a module written in the `#racket` language (i.e., regular Racket) and then a separate module written in `#datalog` and the two can talk to each other!
“A touch! A distinct touch!” cried Holmes. "You are developing a certain unexpected vein of pawky humour, Watson, against which I must learn to guard myself".
-- from "The Valley of Fear" by Arthur Conan Doyle.
Others have more complete answers, but the value for me of learning Prolog (in college) was being awakened to a refreshingly different way of expressing a program. Instead of saying "do this and this and this", you say "here's what it would mean for the program to be done".
At work, I bridged the gap between task tracking software and mandatory reports (compliance, etc.). Essentially, it handles distributing the effective working hours of workers across projects, according to a varied and very detailed set of constraints (people take time off, leave the company and come back, sick days, different holidays for different remote workers, folks work on multiple stuff at the same time, have gaps in task tracking, etc.).
In the words of a colleague responsible for said reports it 'eliminated the need for 50+ people to fill timesheets, saves 15 min x 50 people x 52 weeks per year'
It has been (and still is) in use for 10+years already. I'd say 90% of the current team members don't even know the team used to have to "punch a clock" or fill timesheets way back.
Any kind of problem involving the construction, search or traversal of graphs of any variety from cyclic semi-directed graphs to trees, linear programming, constraint solving, compilers, databases, formal verification of any kind not just theorem proving, computational theory, data manipulation, and in general anything.
You might have forgotten the language but I bet it must have had some influence on how you think or write programs today. I don’t think the value of learning Prolog is necessarily that you can then write programs in Prolog, but that it shifts your perspective and adds another dimension to how you approach problems. At least this is what it has done for me and I find that still valuable today.
I am once again shilling the idea that someone should find a way to glue Prolog and LLMs together for better reasoning agents.
https://news.ycombinator.com/context?id=43948657
Thesis:
1. LLMs are bad at counting the number of r's in strawberry.
2. LLMs are good at writing code that counts letters in a string.
3. LLMs are bad at solving reasoning problems.
4. Prolog is good at solving reasoning problems.
5. ???
6. LLMs are good at writing prolog that solves reasoning problems.
Common replies:
1. The bitter lesson.
2. There are better solvers, ex. Z3.
3. Someone smart must have already tried and ruled it out.
Successful experiments:
1. https://quantumprolog.sgml.net/llm-demo/part1.html
> "4. Prolog is good at solving reasoning problems."
Plain Prolog's way of solving reasoning problems is effectively:
You hard code some options, write a logical condition with placeholders, and Prolog brute-forces every option in every placeholder. It doesn't do reasoning.Arguably it lets a human express reasoning problems better than other languages by letting you write high level code in a declarative way, instead of allocating memory and choosing data types and initializing linked lists and so on, so you can focus on the reasoning, but that is no benefit to an LLM which can output any language as easily as any other. And that might have been nice compared to Pascal in 1975, it's not so different to modern garbage collected high level scripting languages. Arguably Python or JavaScript will benefit an LLM most because there are so many training examples inside it, compared to almost any other langauge.
Even in your example (which is obviously not correct representation of prolog), that code will work X orders magnitude faster and with 100% reliability compared to much more inferior LLM reasoning capabilities.
This is not the point though
Algorithmically there's nothing wrong with using BFS/DFS to do reasoning as long as the logic is correct and the search space is constrained sufficiently. The hard part has always been doing the constraining, which LLMs seem to be rather good at.
What makes you think your brain isn't also brute forcing potential solutions subconciously and only surfacing the useful results?
Can you try calculating 101 * 70 in your head?
Very easy to solve, just like it is easy to solve many other ones once you know the tricks.
I recommend this book: https://www.amazon.com/Secrets-Mental-Math-Mathemagicians-Ca...
Completely missing the point on purpose?
I think therefore I am calculator?
Um, that's really easy to do in your head, there's no carrying or anything? 7,070
7 * 101 = 707 * 10 = 7,070
And computers don't brute-force multiplication either, so I'm not sure how this is relevant to the comment above?
I think it is very relevant, because no brute-forcing is involved in this solution.
It’s almost like you’re proving the point of his reply…
human brains are insanely powerful pattern matching and shortcut-taking machines. There's very little brute forcing going on.
Just intuition ;)
Of course it does "reasoning", what do you think reasoning is? From a quick google: "the action of thinking about something in a logical, sensible way". Prolog searches through a space of logical proposition (constraints) and finds conditions that lead to solutions (if one exists).
(a) Trying adding another 100 or 1000 interlocking proposition to your problem. It will find solutions or tell you one doesn't exist. (b) You can verify the solutions yourself. You don't get that with imperative descriptions of problems. (b) Good luck sandboxing Python or JavaScript with the treat of prompt injection still unsolved.
As someone who did deep learning research 2017-2023, I agree. "Neurosymbolic AI" seems very obvious, but funding has just been getting tighter and more restrictive towards the direction of figuring out things that can be done with LLMs. It's like we collectively forgot that there's more than just txt2txt in the world.
I am once again shilling the idea that someone should find a way to glue Prolog and LLMs together for better reasoning agents.
There are definitely people researching ideas here. For my own part, I've been doing a lot of work with Jason[1], a very Prolog like logic language / agent environment with an eye towards how to integrate that with LLMs (and "other").
Nothing specific / exciting to share yet, but just thought I'd point out that there are people out there who see potential value in this sort of thing and are investigating it.
[1]: https://github.com/jason-lang/jason
Related: LLMs trained on "A is B" fail to learn "B is A"
https://arxiv.org/abs/2309.12288
We've done this, and it works. Our setup is to have some agents that synthesize Prolog and other types of symbolic and/or probabilistic models. We then use these models to increase our confidence in LLM reasoning and iterate if there is some mismatch. Making synthesis work reliably on a massive set of queries is tricky, though.
Imagine a medical doctor or a lawyer. At the end of the day, their entire reasoning process can be abstracted into some probabilistic logic program which they synthesize on-the-fly using prior knowledge, access to their domain-specific literature, and observed case evidence.
There is a growing body of publications exploring various aspects of synthesis, e.g. references included in [1] are a good starting point.
[1] https://proceedings.neurips.cc/paper_files/paper/2024/file/8...
Prolog doesn't look like javascript or python so:
1. web devs are scared of it.
2. not enough training data?
I do remember having to wrestle to get prolog to do what I wanted but I haven't written any in ~10 years.
It's been a while since I have done web dev, but web devs back then were certainly not scared of any language. Web devs are like the ultimate polyglots. Or at least they were. I was regularly bouncing around between a half dozen languages when I was doing pro web dev. It was web devs who popularized numerous different languages to begin with simply because delivering apps through a browser allowed us a wide variety of options.
I have the complete opposite view of web developers. :)
Maybe the ones these days are different. I left the field probably 15 years ago.
Can't find the links right now, but there were some papers on llm generating prolog facts and queries to ground the reasoning part. Somebody else might have them around.
There's a lot of work in this area. See e.g., the LoRP paper by Di et al. There's also a decent amount of work on the other side too, i.e., using LLMs to convert Prolog reasoning chains back into natural language.
Wouldn’t that be like a special case of neuro-symbolic programming?! There are plenty of research going on
IIRC IBM’s Watson (the one that played Jeopardy) used primitive NLP (imagine!) to form a tree of factual relations and then passed this tree to construct Prolog queries that would produce an answer to a question. One could imagine that by swapping out the NLP part with an LLM, the model would have 1. a more thorough factual basis against which to write Prolog queries and 2. a better understanding of the queries it should write to get at answers (for instance, it may exploit more tenuous relations between facts than primitive NLP).
Please tell me that's approximately what Palantir Ontology is, because if it isn't, I've no idea what it could be.
YES! I've run a few experiments on classical logic problems and an LLM can spit out Prolog programs to solve the puzzel. Try it yourself, ask an LLM to write some prolog to solve some problem and then copy paste it to https://swish.swi-prolog.org/ and see if it runs.
@goblinqueen, you around?
@YeGoblynQueenne Dunno if it will ping the person
You might find Eugene Asahara's detailed Prolog in the LLM Era series of about a dozen blog posts very useful - https://eugeneasahara.com/category/prolog-in-the-llm-era/
> LLMs are bad at counting the number of r's in strawberry.
This is a tokenization issue, not an LLM issue.
yes
Prolog really is such a fantastic system, if I can justify its usage then I won't hesitate to do so. Most of the time I'll call a language that I find to be powerful a "power tool", but that doesn't apply here. Prolog is beyond a power tool. A one-off bit of experimental tech built by the greatest minds of a forgotten generation. You'd it find deep in irradiated ruins of a dead city, buried far underground in a bunker easily missed. A supercomputer with the REPL's cursor flickering away in monochrome phosphor. It's sitting there, forgotten. Dutifully waiting for you to jack in.
When I entered university for my Bachelors, I was 28 years old and already worked for 5 or 6 years as a self-taught programmer in the industry. In the first semester, we had a Logic Programming class and it was solely taught in Prolog. At first, I was mega overwhelmed. It was so different than anything I did before and I had to unlearn a lot of things that I was used to in "regular" programming. At the end of the class, I was a convert! It also opened up my mind to functional programming and mathematical/logical thinking in general.
I still think that Prolog should be mandatory for every programmer. It opens up the mind in such a logical way... Love it.
Unfortunately, I never found an opportunity in my 11 years since then to use it in my professional practice. Or maybe I just missed the opportunities?????
Did they teach you how to use DCGs? A few months ago I used EDCGs as part of a de-spaghettification and bug fixing effort to trawl a really nasty 10k loc sepples compilation unit and generate tags for different parts of it. Think ending up with a couple thousand ground terms like:
tag(TypeOfTag, ParentFunction, Line).
Type of tag indicating things like an unnecessary function call, unidiomatic conditional, etc.
I then used the REPL to pull things apart, wrote some manual notes, and then consulted my complete knowledgebase to create an action plan. Pretty classical expert system stuff. Originally I was expecting the bug fixing effort to take a couple of months. 10 days of Prolog code + 2 days of Prolog interaction + 3 days of sepples weedwacking and adjusting the what remained in the plugboard.
This sounds interesting. Perhaps you could write a blog post about it? I'm always looking for use cases for Prolog
In university, Learning prolog was my first encounter with the idea that my IQ may not be as high as I thought
I also found it mindbending.
But some parts, like e.g. the cut operator is something I've copied several times over for various things. A couple of prototype parser generators for example - allowing backtracking, but using a cut to indicate when backtracking is an error can be quite helpful.
"Keep your exclamation points under control. You are allowed no more than two or three per 100,000 words of prose."
Elmore Leonard, on writing. But he might as well have been talking about the cut operator.
At uni I had assignments where we were simply not allowed to use it.
I thoroughly enjoyed doing all the exercises. It was challenging and hence, fun!
I don't think I ever learned how it can be useful other than feeding the mind.
intro to quantum physics for me (which is only sophomore) I noped out of advanced math/physics at that point, luckily I did learn to code on my own
I had more success with the Prolog language track on https://exercism.org/tracks/prolog
It's a mind-bending language and if you want to experience the feeling of learning programming from the beginning again this would be it
I remember a project I did in undergrad with Prolog that would fit connecting parts of theoretical widgets together based on constraints about how different pieces could connect and it just worked instantly and it felt like magic because I had absolutely no clue how I would have coded that in Pascal or COBOL at that time. It blew my mind because the program was so simple.
I've recently started modeling some of my domains/potential code designs in Prolog. I'm not that advanced. I don't really know Prolog that well. But even just using a couple basic prolog patterns to implement a working spec in the 'prolog way' is *unbelievably* useful for shipping really clean code designs to replace hoary old chestnut code. (prolog -> ruby)
I keep wishing for "regex for prolog", ie: being able to (in an arbitrary language) express some functional bits in "prolog-ish", and then be able to ask/query against it.
(not exactly that, but hopefully you get the gist)There's so much stuff regarding constraints, access control, relationship queries that could be expressed "simply" in prolog and being able to extract out those interior buts for further use in your more traditional programming language would be really helpful! (...at least in my imagination ;-)
What you mean is not "regex for Prolog" but an embedded PROLOG interpreter, which exists.
Ironically, the most common way I have seen people do this is use an embedded LISP interpreter, in which a small PROLOG is easily implemented.
https://www.metalevel.at/lisprolog/ suggests Lisprolog (Here are some embedded LISPs: ECL, PicoLisp, tulisp)
SWI-Prolog can also be linked against C/C++ code: https://stackoverflow.com/questions/65118493/is-there-any-re... https://sourceforge.net/p/gprolog/code/ci/457f7b447c2b9e90a0...
Racklog is an embedded PROLOG for Racket (Scheme): https://docs.racket-lang.org/racklog/
There are a bunch of libraries that will do this - here's one example of a python one: https://github.com/yuce/pyswip - and a ruby one: https://github.com/preston/ruby-prolog
Thanks for the reference! `pyswip` is the closest I've seen so far:
...will definitely keep it in my back pocket!pyswip is a one-way python-to-SWI-prolog interface; there's also a first-party (maintained as part of SWI-prolog), two-way one called janus-swi.
https://pypi.org/project/janus-swi/
https://www.swi-prolog.org/pldoc/man?section=janus-call-prol...
You can do that in Racket, with the Racklog library¹. There's also Datalog² and MiniKanren and probably some other logic languages available.
[1] https://docs.racket-lang.org/racklog/index.html
[2] https://docs.racket-lang.org/datalog/index.html
You might be interested in Flix:
https://play.flix.dev/?q=PQgECUFMBcFcCcB2BnUBDUBjA9gG15JtAJb...
is an embedded Datalog DB and query in a general-purpose programming language.
More examples on https://flix.dev/
While usually using native syntax rather than strings, somethign like that exists for most languages of any popularity (and many obscure ones), in the form of miniKanren implementations.
https://minikanren.org/
If you really want something that takes Prolog strings instead (and want the full power of prolog), then there are bindings to prolog interpreters from many languages, and also SWI-Prolog specifically provides a fairly straightforward JSON-based server mode "Machine Query Interface" that should be fairly simple to interface with any language.
https://www.swi-prolog.org/pldoc/man?section=mqi-overview
You could try picat
[0] https://picat-lang.org/
I've wished for the same kind of 'embed prolog in my ruby' for enumerating all possible cases, all invalid cases, etc in test suites. Interesting to know it's not just me!
There are a bunch of libraries that will do this - here's one example of a python one: https://github.com/yuce/pyswip - and a ruby one: https://github.com/preston/ruby-prolog
I did try ruby-prolog. The deeper issue is that its just not prolog. Writing in actual prolog affords a lot of clarity and concision which would be quite noisy in ruby-prolog. To me, the difference was stark enough it wasn't worth any convenience already being in ruby was worth.
Maybe try a Ruby Kanren implementation:
https://minikanren.org/
uKanren is conceptually small and simple, here's a Ruby implementation: https://github.com/jsl/ruby_ukanren
I studied prolog back in 2014. It was used in AI course. I found it very confusing: trying to code A*, N-Queens, or anything in it was just too much. Python, in contrast, was a god-send. I failed the subject twice in my MSc (luckily passing the MSc was based on the total average), but did a similar course in UC Berkeley, with python: aced it, loved it, and learned a lot.
Never again :D
A similar thing happened at my university in an Advanced Algorithms course. Students failed it so much, the university was forced to make the course easier to pass, by removing the minimum grade to pass.
I believe your case (and many other students) is that you couldn't abstract yourself from imperative programming (python) into logic programming (prolog).
It's a query language for graph database. You can write A* and N-Queens in SQL, but why?
I remember writing a Prolog(ish) interpreter in Common Lisp in an 90's AI course in grad school for Theorem proving (which is essentially what Prolog is doing under the hood). Really foundational to my understanding of how declarative programming works. In an ideal world I would still be programming in Lisp and using Prolog tools.
> In an ideal world…
I see this sentiment a lot lately. A sense of missed nostalgia.
What happened?
In 20 years, will people reminisce about JavaScript frameworks and reminisce how this was an ideal world??
I can tell you, from the year 2045, that running the worlds global economy on Javascript was the direct link to the annihilation of most of our freedom and existence. Hope this helps.
Lucky you and your multiverse. In our multiverse we vibe coded the economy until the LLM decided we needed to construct more paperclips.
Speaking as someone who just started exploring Prolog and lisp, and ended up in the frozen north isolated from internet - access. The tools were initially locked/commercial only during a critical period, and then everyone was oriented around GUIs - and GUI environments were very hostile to the historical tools, and thus provided a different kind of access barrier.
A side one is that the LISP ecology in the 80s was hostile to "working well with others" and wanted to have their entire ecosystem in their own image files. (which, btw, is one of the same reasons I'm wary of Rust cough)
Really, it's only become open once more with the rise of WASM, systemic efficiency of computers, and open source tools finally being pretty solid.
I also see the CL or Tcl+C or Assembly as an ideal world.
Is there a WebAssembly WASI version of swi prolog ?
Declarative languages are fantastic to reason about code.
But the true power is unlocked once the underlying libraries are implemented in a way that surpassesthe performance that a human can achieve.
Since implementation details are hidden, caches and parallelism can be added without the programmer noticing anything else than a performance increase.
This is why SQL has received a boost the last decade with massively parallel implementations such as BigQuery, Trino and to some extent DuckDB. And what about adding a CUDA backend?
But all this comes at a cost and needs to be planned so it is only used when needed.
Hah. Found this book back at my dad's this past winter: https://imgur.com/a/CyG1E2P
Had never heard of it before, and this is first I'm hearing of it since.
Also had other cool old shit, like CIB copies of Borland Turbo Pascal 6.0, old Maxis games, Windows 3.1
I'll never understand how it's a programming language not a graph database with query language. It's more MongoDb than Fortran.
But I don't wanna!
I love Prolog, and have seen so many interesting use cases for it.
In the end though, it mostly just feels enough of a separate universe to any other language or ecosystem I'm using for projects that there's a clear threshold for bringing it in.
If there was a really strong prolog implementation with a great community and ecosystem around, in say Python or Go, that would be killer. I know there are some implementations, but the ones I've looked into seem to be either not very full-blown in their Prolog support, or have close to non-existent usage.
The background image says "testing version" - is there a production version?
is prolog a use-case language or is it as versatile as python?
Python wins out in the versatility conversation because of its ecosystem, I'm still kinda convinced that the language itself is mid.
Prolog has many implementations and you don't have the same wealth of libraries, but yes, it's Turing complete and not of the "Turing tarpit" variety, you could reasonably write entire applications in SWI-Prolog.
Right, Python is usually the second-best choice for a language for any problem --- arguably the one thing it is best at is learning to program (in Python) --- it wins based on ease-of-learning/familiarity/widespread usage/library availability.
Personally I find Python more towards the bottom of the list with me, despite being the language I learned on. Especially if the code involved is "pythonic". Just doesn't jive with my neurochemistry. All the problems of C++ with much greater ambiguity, and I've never really been impressed with the library ecosystem. Yeah there's a lot, but just like with node it's just a mountain of unusably bad crap.
I think lua is the much better language for a wide variety of reasons (Most of the good Python libraries are just wrappers around C libraries, which is necessary because Python's FFI is really substandard), but I wouldn't reach for python or lua if I'm expecting to write more than 1000 lines of code. They both scale horribly.
I don't know if I would say its second-best. It just happened to get really popular because it has relatively easy syntax, and Numpy is a really great library making all of those scientific packages that people were using Fortran and C++ for before available in an easier language. This boosted the language, right when data science became a thing, right when dynamic programming became popular, right when there was a boost in Learn 2 Code forget about learning fundamentals was a thing. Its an okay language I guess, but I really think it was lucky that Numpy exists and Numby or Numphp.
More like 3rd to 5th best is most categories. There's just a lot of categories.
Its ease of use and deployment give it a lot more staying power.
The syntax is also pretty nice.
In theory, it's as versatile as Python et al[0] but if you're using it for, e.g., serving bog-standard static pages over HTTP, you're very much using an industrial power hammer to apply screws to glass - you can probably make it work but people will look at you funny.
[0] Modulo that Python et al almost certainly have order(s) of magnitude more external libraries etc.
> you can probably make it work but people will look at you funny
Don't threaten me with a good time
FWIK; You can't compare the two. Python is far more general and larger than Prolog which is more specialized. However there have been various extensions to Prolog to make it more general. See Extensions section in Prolog wikipedia page - https://en.wikipedia.org/wiki/Prolog#Extensions Eg. Prolog++ - https://en.wikipedia.org/wiki/Prolog%2B%2B to allow one to do large-scale OO programming with Prolog.
Earlier, Prolog was used in AI/Expert Systems domains. Interestingly it was also used to model Requirements/Structured Analysis/Structured Design and in Prototyping. These usages seems interesting to me since there might be a way to use these techniques today with LLMs to have them generate "correct" code/answers.
For Prolog and LLMs see - https://news.ycombinator.com/item?id=45712934
Some old papers/books that i dug up and seem relevant;
Prototyping analysis, structured analysis, Prolog and prototypes - https://dl.acm.org/doi/10.1145/57216.57230
Prolog and Natural Language Analysis by Fernando C. N. Pereira and Stuart M. Shieber (free digital edition) - http://www.mtome.com/Publications/PNLA/pnla.html
The Application of Prolog to Structured Design - https://www.researchgate.net/publication/220281904_The_Appli...
Do you mean Northern Conservative Baptist Great Lakes Region Council of 1879 standard Prolog?[2]
SWI Prolog (specifically, see [2] again) is a high level interpreted language implemented in C, with an FFI to use libraries written in C[1], shipping with a standard library for HTTP, threading, ODBC, desktop GUI, and so on. In that sense it's very close to Python. You can do everyday ordinary things with it, like compute stuff, take input and output, serve HTML pages, process data. It starts up quickly, and is decently performant within its peers of high level GC languages - not v8 fast but not classic Java sluggish.
In other senses, it's not. The normal Algol-derivative things you are used to (arithmetic, text, loops) are clunky and weird. It's got the same problem as other declarative languages - writing what you want is not as easy as it seemed like it was going to be, and performance involves contorting your code into forms that the interpreter/compiler is good with.
It's got the problems of functional languages - everything must be recursion. Having to pass the whole world state in and out of things. Immutable variables and datastructures are not great for performance. Not great for naming either, temporary variable names all over.
It's got some features I've never seen in other languages - the way the constraint logic engine just works with normal variables is cool. Code-is-data-is-code is cool. Code/data is metaprogrammable in a LISP macro sort of way. New operators are just another predicate. Declarative Grammars are pretty unique.
The way the interpreter will try to find any valid path through your code - the thing which makes it so great for "write a little code, find a solution" - makes it tough to debug why things aren't working. And hard to name things, code doesn't do things it describes the relation of states to each other. That's hard to name on its own, but it's worse when you have to pass the world state and the temporary state through a load of recursive calls and try to name that clearly, too.
This is fun:
It's a recursive countdown. There's no deliberate typos in it, but it won't work. The reason why is subtle - that code is doing something you can't do as easily in Python. It's passing a Prolog source code expression of X-1 into the recursive call, not the result of evaluating X-1 at runtime. That's how easy metaprogramming and code-generation is! That's why it's a fun language! That's also how easy it is to trip over "the basics" you expect from other languages.It's full of legacy, even more than Python is. It has a global state - the Prolog database - but it's shunned. It has two or three different ways of thinking about strings, and it has atoms. ISO Prolog doesn't have modules, but different implementations of Prolog do have different implementations of modules. Literals for hashtables are contentious (see [2] again). Same for object orientation, standard library predicates, and more.
[1] https://www.swi-prolog.org/pldoc/man?section=foreign
[2] https://news.ycombinator.com/item?id=26624442
Prolog is easily one of my favorite languages, and as many others in this thread, I first encountered it during university. I ended up teaching it for a couple of years (along with Haskell) and ever since, I've gone on an involuntary prolog bender of sorts once or twice a year. I almost always use it for Advent of code as well.
There seems to an interesting difference between Prolog and conventional (predicate) logic.
In Prolog, anything that can't be inferred from the knowledge base is false. If nothing about "playsAirGuitar(mia)" is implied by the knowledge base, it's false. All the facts are assumed to be given; therefore, if something isn't given, it must be false.
Predicate logic is the opposite: If I can't infer anything about "playsAirGuitar(mia)" from my axioms, it might be true or false. It's truth value is unknown. It's true in some model of the axioms, and false in others. The statement is independent of the axioms.
Deductive logic assumes an open universe, Prolog a closed universe.
This is called the Closed World Assumption (CWA) - https://en.wikipedia.org/wiki/Closed-world_assumption
Prolog’s Closed-World Assumption: A Journey Through Time - https://medium.com/@kenichisasagawa/prologs-closed-world-ass...
Is Prolog really based on the closed-world assumption? - https://stackoverflow.com/questions/65014705/is-prolog-reall...
I really enjoyed learning Prolog in university, but it is a weird language. I think that 98% of tasks I would not want to use Prolog for, but for that remaining 2% of tasks it's extremely well suited for. I have always wished that I could easily call Prolog easily from other languages when it suited the use case, however good luck getting most companies to allow writing some code in Prolog.
That is where Lisp or Scheme weirdly shines. It is incredibly easy to add prolog to a Lisp or a Scheme. It’s almost as if it comes out naturally if you just go down the rabbit hole.
“The little prover” is a fantastic book for that. The whole series is.
I worked through the little scheme but not the little prover, I think Ill take a look at that. Thanks.
One can of course add the same stuff to other languages in form of libraries and stuff, but lisp/scheme make it incredibly easy to make it look like part of the language itself and make seem a mere extension of the language. So you can have both worlds if you want to. Lisp/scheme is not dead.
In fact, in recent years people have started contributing again and are rediscovering the merits.
Racket really shines in this regard: Racket makes it easy to build little DSLs, but they all play perfectly together because the underlying data model is the same. Example from the Racket home page: https://racket-lang.org/#any-syntax
You can have a module written in the `#racket` language (i.e., regular Racket) and then a separate module written in `#datalog` and the two can talk to each other!
Always felt this would be language that Sherlock Holmes would use...so be sure to wear the hat when learning it
“A touch! A distinct touch!” cried Holmes. "You are developing a certain unexpected vein of pawky humour, Watson, against which I must learn to guard myself".
-- from "The Valley of Fear" by Arthur Conan Doyle.
Two Prolog books that I find very interesting:
Advanced Turbo prolog - https://archive.org/details/advancedturbopro0000schi/mode/2u...
Prolog programming for artificial intelligence - https://archive.org/details/prologprogrammin0000brat_l1m9/mo...
What kind of problems is Prolog helping to solve besides GOFAI, theorem proving and computational linguistics?
Others have more complete answers, but the value for me of learning Prolog (in college) was being awakened to a refreshingly different way of expressing a program. Instead of saying "do this and this and this", you say "here's what it would mean for the program to be done".
At work, I bridged the gap between task tracking software and mandatory reports (compliance, etc.). Essentially, it handles distributing the effective working hours of workers across projects, according to a varied and very detailed set of constraints (people take time off, leave the company and come back, sick days, different holidays for different remote workers, folks work on multiple stuff at the same time, have gaps in task tracking, etc.).
In the words of a colleague responsible for said reports it 'eliminated the need for 50+ people to fill timesheets, saves 15 min x 50 people x 52 weeks per year'
It has been (and still is) in use for 10+years already. I'd say 90% of the current team members don't even know the team used to have to "punch a clock" or fill timesheets way back.
Any kind of problem involving the construction, search or traversal of graphs of any variety from cyclic semi-directed graphs to trees, linear programming, constraint solving, compilers, databases, formal verification of any kind not just theorem proving, computational theory, data manipulation, and in general anything.
Scheduling, relational modeling, parsing. These things come up all the time. Look at DCG:s if you want to quickly become dangerous.
See my comment here - https://news.ycombinator.com/item?id=45902960
Learn it now? I learned back in the 80s... and have since forgotten
You might have forgotten the language but I bet it must have had some influence on how you think or write programs today. I don’t think the value of learning Prolog is necessarily that you can then write programs in Prolog, but that it shifts your perspective and adds another dimension to how you approach problems. At least this is what it has done for me and I find that still valuable today.
There are declarative languages like SQL and XSLT.
And then there are declarative languages like Prolog.
yes
We had it in university courses and it seemed useless. DSL for backtracking.