6 ms·

I wonder... is it still justified to learn Prolog now? Aren't there better alternatives for logic programming in many other common programming languages? I mean

by qart 6y ago

I wonder... is it still justified to learn Prolog now? Aren't there better alternatives for logic programming in many other common programming languages? I mean http://minikanren.org/ http://minikanren.org/

triska 6y ago
How is this a better alternative? A major attraction of Prolog is that one can remove almost arbitrary parts of any pure program and still infer useful conclusions that hold for the original program. For example, one can remove a clause and thereby make the program more specific. One can remove a goal and thus make the program more general. This is possible due to the way the language is designed, the interplay of syntax and semantics enables this. The program fragments serve as explanations that can be shown to programmers to pinpoint mistakes in the code. Thus, when narrowing down mistakes, it becomes possible to focus on smaller portions of the code that are therefore easier to understand.
- iso8859-1 6y ago
  Why wouldn't that be the case for e.g. LogicT? Prolog is _larger_ than LogicT. It is the additional syntax and runtime system in a custom Prolog implementation that needs to be defended, not the lack of it!
- qart 6y ago
  I meant "better" in the sense that one can do logic programming from whatever language one is familiar with already, instead of installing and learning a whole new ecosystem. We would still have to learn logic programming.
- YeGoblynQueenne 6y ago
  >> For example, one can remove a clause and thereby make the program more specific. One can remove a goal and thus make the program more general. Woa. I'm pretty sure that the subsumption order and the implication order are not common knowledge among Prolog programmers. Have you been reading Plotkin by any chance? :)
sls 6y ago
miniKanren is great. Here[1]'s Will Byrd on the difference between it and Prolog. [1] http://minikanren.org/minikanren-and-prolog.html http://minikanren.org/minikanren-and-prolog.html
abeppu 6y ago
I've spent time trying to wrap my head around ideas in minikanren and move them out of scheme. But while reading and playing with minikanren has been quite illuminating, it has yet to help me solve many "real" naturally occurring problems. And indeed, some of the motivations for minkanren are aesthetic or philosophical stances, rather than pragmatic (wanting to avoid having to use the cut operator etc). Most of the work around minikanren seems more aimed at piloting approaches or techniques which could be used to produce useful tools, rather than actually producing useful tools. But perhaps someone who has used languages in this area more broadly than I can comment: Which is a better bang for your buck? - Prolog - "Functional logic languages" e.g. Curry, Mercury - Clojure + core.logic - scheme + minikanren
iso8859-1 6y ago
There is also LogicT: http://hackage.haskell.org/package/logict http://hackage.haskell.org/package/logict Since you'll eventually need some business logic, I don't see much point in Prolog either nowadays. Prolog-like code is a tiny part of your app, no need for a dedicated syntax. Do-notation is sufficient.
YeGoblynQueenne 6y ago
>> I wonder... is it still justified to learn Prolog now? Unfortunately no. There was a great push to develop the theory of logic programming, based on resolution theorem proving, back in the '70s and '80s. This effort culminated in the design of Prolog, a general-purpose logic programming language with a resolution theorem-prover. Shortly after the AI winter of the '80s hit and research in logic programming was severely disrupted. Research and progress continued but at a much slower pace and the earlier heights have never been reached again since. Consequently, we don't have a "better Prolog" because there are very few people who can even imagine what such a "better Prolog" would look like, let alone design and implement it. Alas, we have ran out of Robinsons, Kowalskis, Colmerauers, and so on. Another reason of course is that Prolog is a very fine-tuned language that gets many things right because its design makes very sensible trade-offs. For example, the much-maligned depth-first search and the consequent clause ordering, absence of an occurs check, negation-as-failure, extra-logical features such as the dynamic program database, etc, are all pragmatic choices that balance the need for a general-purpose language that works, with aspirations of theoretical purity. That is to say, there is nothing fundamentally broken about Prolog, it's acutally a very good logic programming language and it's just not that easy to design a radically better logic progamming language, especially one based on resolution. Regarding minikanren, my understanding is that it's not meant as a "better Prolog", rather it's meant as a small, embedded Prolog (and here by "Prolog" I mean a logic programming language based on resolution, in the same sense that Scheme is "a Lisp"). It's meant for programmers of imperative languages who would like to integrate logic programing functionality in their applications. Minikanrens (there are many) can essentially be imported as libraries that allow logic programming in a syntax closer to the embedding language. The alternative would be either to switch entirely to Prolog (which of course is a huge decision), or to write a buggy, slow version of Prolog in the programmer's preferred imperative language. Minikanrens have various differences with Prolog, such as absence of side-effects and a dynamic database, a different search strategy, occurs check, etc. but these are not unmitigated improvements. They are different trade-offs than the ones chosen by Prolog. Note however that resolution-based languages like Prolog are not the only logic programming languages. For two prominent examples of alternative approaches, see Datalog and Answer Set Progamming. Both sacrifice Turing-completeness but offer, e.g. decidability, the ability to benefit from the power of modern SAT solvers, classical negation, etc. Again, there are trade-offs. The thing to understand is that theorem proving -proving the truth or falsehood of statements in a formal language- is damn hard, even with computers, and there are always going to be trade-offs when the purpose is to have a real-world application.

by qart 6y ago

triska 6y ago

How is this a better alternative? A major attraction of Prolog is that one can remove almost arbitrary parts of any pure program and still infer useful conclusions that hold for the original program. For example, one can remove a clause and thereby make the program more specific. One can remove a goal and thus make the program more general. This is possible due to the way the language is designed, the interplay of syntax and semantics enables this. The program fragments serve as explanations that can be shown to programmers to pinpoint mistakes in the code. Thus, when narrowing down mistakes, it becomes possible to focus on smaller portions of the code that are therefore easier to understand.

iso8859-1 6y ago
Why wouldn't that be the case for e.g. LogicT? Prolog is _larger_ than LogicT. It is the additional syntax and runtime system in a custom Prolog implementation that needs to be defended, not the lack of it!
qart 6y ago
I meant "better" in the sense that one can do logic programming from whatever language one is familiar with already, instead of installing and learning a whole new ecosystem. We would still have to learn logic programming.
YeGoblynQueenne 6y ago
>> For example, one can remove a clause and thereby make the program more specific. One can remove a goal and thus make the program more general. Woa. I'm pretty sure that the subsumption order and the implication order are not common knowledge among Prolog programmers. Have you been reading Plotkin by any chance? :)

sls 6y ago

miniKanren is great. Here[1]'s Will Byrd on the difference between it and Prolog. [1] http://minikanren.org/minikanren-and-prolog.html http://minikanren.org/minikanren-and-prolog.html

abeppu 6y ago

I've spent time trying to wrap my head around ideas in minikanren and move them out of scheme. But while reading and playing with minikanren has been quite illuminating, it has yet to help me solve many "real" naturally occurring problems. And indeed, some of the motivations for minkanren are aesthetic or philosophical stances, rather than pragmatic (wanting to avoid having to use the cut operator etc). Most of the work around minikanren seems more aimed at piloting approaches or techniques which could be used to produce useful tools, rather than actually producing useful tools. But perhaps someone who has used languages in this area more broadly than I can comment: Which is a better bang for your buck? - Prolog - "Functional logic languages" e.g. Curry, Mercury - Clojure + core.logic - scheme + minikanren

iso8859-1 6y ago

There is also LogicT: http://hackage.haskell.org/package/logict http://hackage.haskell.org/package/logict Since you'll eventually need some business logic, I don't see much point in Prolog either nowadays. Prolog-like code is a tiny part of your app, no need for a dedicated syntax. Do-notation is sufficient.

YeGoblynQueenne 6y ago

>> I wonder... is it still justified to learn Prolog now? Unfortunately no. There was a great push to develop the theory of logic programming, based on resolution theorem proving, back in the '70s and '80s. This effort culminated in the design of Prolog, a general-purpose logic programming language with a resolution theorem-prover. Shortly after the AI winter of the '80s hit and research in logic programming was severely disrupted. Research and progress continued but at a much slower pace and the earlier heights have never been reached again since. Consequently, we don't have a "better Prolog" because there are very few people who can even imagine what such a "better Prolog" would look like, let alone design and implement it. Alas, we have ran out of Robinsons, Kowalskis, Colmerauers, and so on. Another reason of course is that Prolog is a very fine-tuned language that gets many things right because its design makes very sensible trade-offs. For example, the much-maligned depth-first search and the consequent clause ordering, absence of an occurs check, negation-as-failure, extra-logical features such as the dynamic program database, etc, are all pragmatic choices that balance the need for a general-purpose language that works, with aspirations of theoretical purity. That is to say, there is nothing fundamentally broken about Prolog, it's acutally a very good logic programming language and it's just not that easy to design a radically better logic progamming language, especially one based on resolution. Regarding minikanren, my understanding is that it's not meant as a "better Prolog", rather it's meant as a small, embedded Prolog (and here by "Prolog" I mean a logic programming language based on resolution, in the same sense that Scheme is "a Lisp"). It's meant for programmers of imperative languages who would like to integrate logic programing functionality in their applications. Minikanrens (there are many) can essentially be imported as libraries that allow logic programming in a syntax closer to the embedding language. The alternative would be either to switch entirely to Prolog (which of course is a huge decision), or to write a buggy, slow version of Prolog in the programmer's preferred imperative language. Minikanrens have various differences with Prolog, such as absence of side-effects and a dynamic database, a different search strategy, occurs check, etc. but these are not unmitigated improvements. They are different trade-offs than the ones chosen by Prolog. Note however that resolution-based languages like Prolog are not the only logic programming languages. For two prominent examples of alternative approaches, see Datalog and Answer Set Progamming. Both sacrifice Turing-completeness but offer, e.g. decidability, the ability to benefit from the power of modern SAT solvers, classical negation, etc. Again, there are trade-offs. The thing to understand is that theorem proving -proving the truth or falsehood of statements in a formal language- is damn hard, even with computers, and there are always going to be trade-offs when the purpose is to have a real-world application.