Comment by YeGoblynQueenne
Comment by YeGoblynQueenne 15 hours ago
>> If you prefer just the practical side of things then that's a lot easier to explain: I didn't like working with Prolog.
Great, but that's aesthetics. You'd save a lot of time by being upfront about that. De gustibus non est disputandum.
I note that your aversion for Prolog comes from a course you had in -undergrad, I think? I fell in love with Prolog in my undergrad course and even undertook a substantial project in it, where I loved it even more- but I didn't really get it until my PhD where I had the time to really sit down and study, not just Prolog as a programming language, but logic programming, as a thing unto itself. I didn't even know what sources to read, and I had read all the Prolog textbooks I could find. That's not to gatekeep, or pull rank, but logic programming is a deep and old subject and one really needs guidance to get to grips with it which you just don't get in undergrad (not least because many tutors themselves aren't that deeply knowledgeable in the subject).
I note also that you seem to have been introduced to Prolog in terms of its vaunted declarative qualities: "you just write the rules". That's probably the worst lie one can tell to students and the worst possible way to introduce Prolog, because, as you found out, Prolog just doesn't work that way. For example, back in my undergrad, I only learned about the "declarative paradigm" much later on and even then I thought it was more of a gimmick, the kind of argument people reach for when they try to convince others to be excited about the same things they're excited. This kind of argument is supposed to go beyond aesthetics, but it fails to do so. For example, why is declarative programming better than procedural? It isn't. It's just a matter of taste.
The first thing I paid attention to about Prolog was "automated theorem proving", which was what blew my mind. I had just noticed the way manual theorem proving proceeds in a very mechanical manner and was thinking it should be possible to write a program to do it, when I found out someone had done it, for real, and much better than I ever could. I don't think that's aesthetics. It's a real, and distinct, capability, that you don't find e.g. in C or Haskell. How important it is, that's again a personal matter. For me, plenty. For others, not so much. De gustibus etc.
The right way to introduce Prolog is the long way around, starting with propositional logic, then FOL, then logic programming, then Resolution, and then only at the end introducing Prolog and other logic programming languages. The way Prolog is taught now, it just doesn't work and everyone leaves university without understanding a thing about it.
I can't give a "serious example" of using Mercury or Curry because I have only checked them out once or twice and don't have experience with them. I don't have anything against them, to be clear, as I don't have anything against Datalog. I prefer Prolog because it's more mature, and its implementations more feature-rich. SWI-Prolog in particular is bedecked with libraries like a swiss army knife and its maintainer is a programming super-hero. But if you like Mercury then you could possibly help with its development, which I understand has slowed down for lack of interest, which is a big shame.
On meta-interpreters, I use one all the time. The Inductive Logic Programming system that I created during my PhD is based on an inductive, second-order Prolog meta-interpreter:
https://github.com/stassa/louise
You'll find the early version of that meta-interpreter in https://github.com/stassa/louise/blob/master/src/vanilla.pl A new version, decoupled from any specific learning system, is in a private repo. Let me know if you're very very interested. A write up is here:
https://hmlr-lab.github.io/pdfs/Second_Order_SLD_ILP2024.pdf
>> Prolog can get stuck in a branch of the search tree that cannot lead to a solution.
There's more ways to execute Prolog than DFS so that you don't get stuck in loops. Obviously there'll always be infinite proof branches because Church-Turing. I'm not sure you fully appreciate that?
Your comment is very fair, indeed perhaps the "way it is taught" is a major problem. Me, personally, I was quite happy to later find out that the "you just write the rules" declarative promise is true, just with caveats, i.e., you have to restrict yourself to a subset of what could otherwise be expressed.
That might seem like an annoying limitation, but to me it is not. Most problems fit well within the bounds, and you get to reap the benefits.
>> There's more ways to execute Prolog than DFS so that you don't get stuck in loops. Obviously there'll always be infinite proof branches because Church-Turing. I'm not sure you fully appreciate that?
It doesn't have to do with Church-Turing. The issue is with DFS specifically which can get stuck in an unproductive search branch. This is mitigated by Mercury with termination checks and mode determinism, and entirely solved by Curry through an execution semantics that guarantees fair search (only way to not terminate is if there is no solution).
If you can execute Prolog in a different manner then I'm happy that's the case but I find it hard to believe that's still Prolog. How would the IO come out in the same order?
>> But if you like Mercury then you could possibly help with its development, which I understand has slowed down for lack of interest, which is a big shame.
Sadly I lack the skillset...
>> I prefer Prolog because it's more mature, and its implementations more feature-rich
My preference for the semantics of the far less popular logic programming languages likely clouds my judgements towards Prolog more than I'd like to admit.