3 ms·

Prolog is a really good query language, in terms of expressiveness. However, once you start bolting on side effects, like I/O and asserting/retracting facts in

Prolog is a really good query language, in terms of expressiveness. However, once you start bolting on side effects, like I/O and asserting/retracting facts in the middle of queries, all declarativeness flies out the window and you're left trying to explicitly juggle the implicit branching and control of the program counter to try to keep the system sane, bringing in more and more of the complexities of imperative programming. Optimization also basically requires wresting control of the program counter back from the abstract system into explicit programmer control. It certainly works as part of practical real-world systems, but I wouldn't necessarily want to write a large, behavior-heavy application purely in Prolog. For large in-RAM data, but light on behavior stuff, fine. There are certain data analyses that are much faster to develop in Prolog than imperatively, and going multi-language can save a lot of programmer time compared to writing everything in $TRADITIONAL_LANGUAGE purely out of inertia.

buzzybee 10y ago
I've definitely gotten the sense that Prolog would make a great library or extension to another, more traditionally-paradigmed language. In the same way that LINQ has received a lot of praise as an extension to C#.
- jhbadger 10y ago
  In a way, that's what https://en.wikipedia.org/wiki/MiniKanren https://en.wikipedia.org/wiki/MiniKanren is -- a backtracking logic mini-language that you embed in another language.
YeGoblynQueenne 10y ago
>> Optimization also basically requires wresting control of the program counter back from the abstract system into explicit programmer control. I'm unsure what this alludes to. Are you talking about minding tail-call optimisation? That's not a feature of Prolog only. >> going multi-language can save a lot of programmer time compared to writing everything in $TRADITIONAL_LANGUAGE purely out of inertia A better idea is to chuck out most of your stack and write most of your application in Prolog itself- no xml, no having to worry about Object-Relational Impedance Mismatch, and so on. You don't even need regular expressions, because writing a compiler in prolog with Definite Clause Grammars is a piece of cake (something that can't be said for any other language under the sun). For instance, see "Can I replace a LAMP stack with Prolog?", here: http://www.swi-prolog.org/FAQ/PrologLAMP.txt http://www.swi-prolog.org/FAQ/PrologLAMP.txt
- white-flame 10y ago
  >> I'm unsure what this alludes to. Are you talking about minding tail-call optimisation? That's not a feature of Prolog only. Many of the optimizations I've seen are ensuring that no branches are explored that the programmer knows are irrelevant once certain unifications have succeeded, and to control the ordering of branch exploration to try to find faster answers first. Indexing is also manual, and while I haven't looked in a few years, I haven't seen any JIT-style heuristic feedback that lets the system optimize itself for the runtime conditions of Prolog programs. In my definitions, which some certainly argue against, declarative means you let the CPU do "whatever it takes" in the background, while imperative has you directly managing where the program counter goes, in what order, including explicit thread management (which Prologs that I've seen make you do as well).
  - YeGoblynQueenne 10y ago
    >> Many of the optimizations I've seen are ensuring that no branches are explored that the programmer knows are irrelevant (...) OK, you're talking about the cut here. I've made some more comments on it above, but basically I don't really see what the problem is, with it. It strikes me as more of a theoretical point to have to worry about. Prolog takes a practical approach to both logic programming and the whole declarativeness thing. That is to say, if you can't have efficiency, you sacrifice some purity so that you can have a language that lets you do work. The cut, along with other program flow control predicates (->/0, ;/0 etc) and predicates with side-effects (write/1, get0/1 etc) are normally discussed under "extra-logical facilities" or some such section of textbooks. We all all understand first-order logic inference is intractable, but we want to run it as a programming language so concessions must be made to material reality. Same goes for every other language- computing efficiently is one half of programming computers (untangling the mess you make is the other half). This is a very old line of criticism and I don't really see the point of it anymore- not after having learned how to use the cut without hurting myself. So maybe it's just a problem in principle, because in practice it's not such a big deal. >> Indexing is also manual, and while I haven't looked in a few years, I haven't seen any JIT-style heuristic feedback that lets the system optimize itself for the runtime conditions of Prolog programs. Swi-Prolog has JIT clause indexing: http://www.swi-prolog.org/pldoc/man?section=jitindex http://www.swi-prolog.org/pldoc/man?section=jitindex The first argument of coumpound terms is indexed, as long as it's atomic- so you do need to understand indexing to make best use of it. I mention a recent case were I made a mess and then untangled it once I realised how I was using indexing wrong. So, you need to know some programming, right? I don't see that as a bad thing. >> explicit thread management (which Prologs that I've seen make you do as well). For multithreaded applications, that's true. I don't know how much of a problem is that in practice because I've never really had to use the facilities, but at least you got immutability to protect you from the usual pain.

buzzybee 10y ago

I've definitely gotten the sense that Prolog would make a great library or extension to another, more traditionally-paradigmed language. In the same way that LINQ has received a lot of praise as an extension to C#.

jhbadger 10y ago
In a way, that's what https://en.wikipedia.org/wiki/MiniKanren https://en.wikipedia.org/wiki/MiniKanren is -- a backtracking logic mini-language that you embed in another language.

YeGoblynQueenne 10y ago

>> Optimization also basically requires wresting control of the program counter back from the abstract system into explicit programmer control. I'm unsure what this alludes to. Are you talking about minding tail-call optimisation? That's not a feature of Prolog only. >> going multi-language can save a lot of programmer time compared to writing everything in $TRADITIONAL_LANGUAGE purely out of inertia A better idea is to chuck out most of your stack and write most of your application in Prolog itself- no xml, no having to worry about Object-Relational Impedance Mismatch, and so on. You don't even need regular expressions, because writing a compiler in prolog with Definite Clause Grammars is a piece of cake (something that can't be said for any other language under the sun). For instance, see "Can I replace a LAMP stack with Prolog?", here: http://www.swi-prolog.org/FAQ/PrologLAMP.txt http://www.swi-prolog.org/FAQ/PrologLAMP.txt

white-flame 10y ago
>> I'm unsure what this alludes to. Are you talking about minding tail-call optimisation? That's not a feature of Prolog only. Many of the optimizations I've seen are ensuring that no branches are explored that the programmer knows are irrelevant once certain unifications have succeeded, and to control the ordering of branch exploration to try to find faster answers first. Indexing is also manual, and while I haven't looked in a few years, I haven't seen any JIT-style heuristic feedback that lets the system optimize itself for the runtime conditions of Prolog programs. In my definitions, which some certainly argue against, declarative means you let the CPU do "whatever it takes" in the background, while imperative has you directly managing where the program counter goes, in what order, including explicit thread management (which Prologs that I've seen make you do as well).
- YeGoblynQueenne 10y ago
  >> Many of the optimizations I've seen are ensuring that no branches are explored that the programmer knows are irrelevant (...) OK, you're talking about the cut here. I've made some more comments on it above, but basically I don't really see what the problem is, with it. It strikes me as more of a theoretical point to have to worry about. Prolog takes a practical approach to both logic programming and the whole declarativeness thing. That is to say, if you can't have efficiency, you sacrifice some purity so that you can have a language that lets you do work. The cut, along with other program flow control predicates (->/0, ;/0 etc) and predicates with side-effects (write/1, get0/1 etc) are normally discussed under "extra-logical facilities" or some such section of textbooks. We all all understand first-order logic inference is intractable, but we want to run it as a programming language so concessions must be made to material reality. Same goes for every other language- computing efficiently is one half of programming computers (untangling the mess you make is the other half). This is a very old line of criticism and I don't really see the point of it anymore- not after having learned how to use the cut without hurting myself. So maybe it's just a problem in principle, because in practice it's not such a big deal. >> Indexing is also manual, and while I haven't looked in a few years, I haven't seen any JIT-style heuristic feedback that lets the system optimize itself for the runtime conditions of Prolog programs. Swi-Prolog has JIT clause indexing: http://www.swi-prolog.org/pldoc/man?section=jitindex http://www.swi-prolog.org/pldoc/man?section=jitindex The first argument of coumpound terms is indexed, as long as it's atomic- so you do need to understand indexing to make best use of it. I mention a recent case were I made a mess and then untangled it once I realised how I was using indexing wrong. So, you need to know some programming, right? I don't see that as a bad thing. >> explicit thread management (which Prologs that I've seen make you do as well). For multithreaded applications, that's true. I don't know how much of a problem is that in practice because I've never really had to use the facilities, but at least you got immutability to protect you from the usual pain.