4 ms·

I'm currently trying to learn Prolog. Reason is because I attempt to reignite my enthusiasm for IT by going back to the roots. And the joy of learning new progr

I'm currently trying to learn Prolog. Reason is because I attempt to reignite my enthusiasm for IT by going back to the roots. And the joy of learning new programming languages / paradigms was what brought me into the field more than 20 years ago. I find Prolog very challenging for several reasons. I identified 3 levels of difficulty with it: 1) Syntax 2) Reasoning and Paradigm 3) Implementation 1) is things like "\=" for not equal. Those are mostly just inconveniences and Prolog's age is showing there. But I still don't have a firm grip on the pattern matching of lists. 2) is the whole stuff around switching mentally from functions to predicates. I often find myself trapped in trying to reason functionally and if I was very proficient in functional programming that might even work. But so far I'm still at the level of trying to wrap my head around the fact that there no return values and that sequencing via comma (which is actually a conjunction - AND) will be evaluated "kind of" procedural by serial evaluation. This makes it seem familiar but conflicts with the actual paradigm. 3) is the most critiqued aspect of it. There are many Prolog implementations it but they all seem to suffer from the same problems. Like Prolog getting lost in some tree which forces the developer to understand what the interpreter is doing to help it find the right branch. Also the aforementioned confusion that logically (A AND B) is identical to (B AND A) but in Prolog isn't and can make the subtle difference between the program finishing successfully or running until memory is consumed. In my opinion there is reason why Prolog is one of those subjects that are brought up here again and again and again but without any justification with regard to something about it being "news". It's a very fascinating paradigm and I find it very sad that it doesn't really get any attention today. Just check the list of literature about it - there's almost nothing and what there is either old or distinctively academic. One reason clearly is the lack of convenient interfacing to other languages. Because even a Prolog genius would probably admit that there is no point in trying to implement anything IO with it. I'm working through Learn Prolog Now. Which is a good book. Already ordered Prolog in Adventures. I could see several projects for it that would be a natural fit but I already anticipate that eventually my enthusiasm will fade at the point where I'm forced to dig into SWI as soon as I leave the toy level. SWI is also kind of weird. It seems to be the best choice but there are surprisingly trivial aspects about it that I find very unsatisfying (I can load a DB with "[filename]." but I cannot purge it before loading another DB without restarting the session ... or does somebody know how that's done?). That's basically what I observe as far as my as well as other people's experience goes with it: very promising and exciting but eventually disappointing. It shouldn't be like that. I also believe that symbolic AI / Prolog and deep learning could very well benefit from each other.

usgroup 3y ago
I'd note two things by way of encouragement: 1. Prolog is often used in things that are kept very secret. There is a relatively small set of professional and highly committed users centered on distributions like SICStus. There is a much larger set of hobbyist/academic users centered on distributions like SWI, Tau, Ciao! and so on. The feature sets of the commercial distributions gives you some idea about the sort of capabilities the hardcore users require. 2. Getting good at solving problems with Prolog is a borderline mystical experience -- or at least it is for me. Seeing the logical structure of problems, their representation through symbolic pattern matching and their solutions as search, is an insight which once seen cannot be unseen. It will condition your perception of problems forever more.
- MockObject 3y ago
  > Prolog is often used in things that are kept very secret. As in national security secrecy?
  - usgroup 3y ago
    No, that's not what I meant. I just mean people not telling other people. For example: Pyrosequencing AB: SICS developed a dispensation order generation algorithm for Pyrosequencing's sequence analysis instruments, using constraint programming with SICStus. The algorithm can be described as a compiler, which calculates an instruction sequence based on an input specification. Applications include genetics, drug discovery, microbiology, SNP and mutation analysis, forensic identification using mtDNA, pharmacogenomics, and bacterial and viral typing. That's a public example from the SICStus website, but you could see why the example above could have remained a secret and their Prolog used along with it. SICStus attracts such cases.
YeGoblynQueenne 3y ago
Unlike usgroup I don't think I can be very encouraging. It is very hard to learn Prolog if you approach it as a programming language rather than an implementation of the Resolution-based logic programming paradigm. I coded in Prolog for many years and I was reasonably proficient in it, but I only really understood it during my PhD when I finally had the time to study logic programming textbooks and understand where it comes from. Unfortunately, that is simply not the amount of time that one has unless one is doing a PhD -and one in a relevant subject, as I did. As a for instance, \=/2 is not "not equal", but "does not unify". So for example A \= B is false, because A and B are variables and unify, a \= b is true because a does not unify with b and a \= B is false again because a unifies with B (as in a = B... which is not equality, or assignment, but unification). I'm guessing that your trouble with pattern matching (i.e. unification) of lists comes from the same place. All this will inevitably and understandably sound downright weird unless you know why unification exists. But that means you need to understand Resolution, and logic programming. Regarding (2), indeed, Prolog predicates are relations, not functions. It might help to think of the er relation between a function, and a relation. Say for example the addition function: x + y = z; or, in Polish ish notation: +(x,y) = z. If you wrote that as a relation: +(x,y,z). Meaning you _could_ see a relation as a function with just one extra argument that holds the return value of the function. If you have trouble transposing the function-like representation of code in your head to a relational one, for Prolog, try doing it that way. Instead of trying to write functions that are replaced by their return values, write functions+return that have one extra variable for the return. So, sort(List) = Sorted becomes sort(List,Sorted). reverse(List) = Reverse, becomes reverse(List,Reversed) and so on. Ingore for a moment the usual comment about how Prolog predicates do not have "return" variables, only terms in some relation. True, but if it's blocking you, avoid thinking about it. Until you can think about it. Btw, the reason that Prolog predicates aren't replaced by their value, not even their truth value, is that Prolog inherits its semantics from First Order Logic (FOL), where there's also no replacement of values. In fact, FOL _has_ functions, but they, too, are not the kind that is replaced by their value. I think that kind of function is only found in programming languages and then not all of them either. The reason for (3) also has to do with Resolution and how it is most efficiently implemented. There are alternatives, e.g. datalog, or Answer Set Programming, which are more purely logical; or Prolog with tabling, a.k.a. SLG-Resolution, which doesn't suffer from left-recursion (what you get when you put a recursive literal first in the body of a clause). >> Because even a Prolog genius would probably admit that there is no point in trying to implement anything IO with it. I'm no Prolog genious, so what does "anything IO" mean?

usgroup 3y ago

I'd note two things by way of encouragement: 1. Prolog is often used in things that are kept very secret. There is a relatively small set of professional and highly committed users centered on distributions like SICStus. There is a much larger set of hobbyist/academic users centered on distributions like SWI, Tau, Ciao! and so on. The feature sets of the commercial distributions gives you some idea about the sort of capabilities the hardcore users require. 2. Getting good at solving problems with Prolog is a borderline mystical experience -- or at least it is for me. Seeing the logical structure of problems, their representation through symbolic pattern matching and their solutions as search, is an insight which once seen cannot be unseen. It will condition your perception of problems forever more.

MockObject 3y ago
> Prolog is often used in things that are kept very secret. As in national security secrecy?
- usgroup 3y ago
  No, that's not what I meant. I just mean people not telling other people. For example: Pyrosequencing AB: SICS developed a dispensation order generation algorithm for Pyrosequencing's sequence analysis instruments, using constraint programming with SICStus. The algorithm can be described as a compiler, which calculates an instruction sequence based on an input specification. Applications include genetics, drug discovery, microbiology, SNP and mutation analysis, forensic identification using mtDNA, pharmacogenomics, and bacterial and viral typing. That's a public example from the SICStus website, but you could see why the example above could have remained a secret and their Prolog used along with it. SICStus attracts such cases.

YeGoblynQueenne 3y ago

Unlike usgroup I don't think I can be very encouraging. It is very hard to learn Prolog if you approach it as a programming language rather than an implementation of the Resolution-based logic programming paradigm. I coded in Prolog for many years and I was reasonably proficient in it, but I only really understood it during my PhD when I finally had the time to study logic programming textbooks and understand where it comes from. Unfortunately, that is simply not the amount of time that one has unless one is doing a PhD -and one in a relevant subject, as I did. As a for instance, \=/2 is not "not equal", but "does not unify". So for example A \= B is false, because A and B are variables and unify, a \= b is true because a does not unify with b and a \= B is false again because a unifies with B (as in a = B... which is not equality, or assignment, but unification). I'm guessing that your trouble with pattern matching (i.e. unification) of lists comes from the same place. All this will inevitably and understandably sound downright weird unless you know why unification exists. But that means you need to understand Resolution, and logic programming. Regarding (2), indeed, Prolog predicates are relations, not functions. It might help to think of the er relation between a function, and a relation. Say for example the addition function: x + y = z; or, in Polish ish notation: +(x,y) = z. If you wrote that as a relation: +(x,y,z). Meaning you _could_ see a relation as a function with just one extra argument that holds the return value of the function. If you have trouble transposing the function-like representation of code in your head to a relational one, for Prolog, try doing it that way. Instead of trying to write functions that are replaced by their return values, write functions+return that have one extra variable for the return. So, sort(List) = Sorted becomes sort(List,Sorted). reverse(List) = Reverse, becomes reverse(List,Reversed) and so on. Ingore for a moment the usual comment about how Prolog predicates do not have "return" variables, only terms in some relation. True, but if it's blocking you, avoid thinking about it. Until you can think about it. Btw, the reason that Prolog predicates aren't replaced by their value, not even their truth value, is that Prolog inherits its semantics from First Order Logic (FOL), where there's also no replacement of values. In fact, FOL _has_ functions, but they, too, are not the kind that is replaced by their value. I think that kind of function is only found in programming languages and then not all of them either. The reason for (3) also has to do with Resolution and how it is most efficiently implemented. There are alternatives, e.g. datalog, or Answer Set Programming, which are more purely logical; or Prolog with tabling, a.k.a. SLG-Resolution, which doesn't suffer from left-recursion (what you get when you put a recursive literal first in the body of a clause). >> Because even a Prolog genius would probably admit that there is no point in trying to implement anything IO with it. I'm no Prolog genious, so what does "anything IO" mean?