5 ms·

I've seen multiple examples of prolog over the years. From looking at them, one gets the idea that you must hardcode all your data into your program and the on

I've seen multiple examples of prolog over the years. From looking at them, one gets the idea that you must hardcode all your data into your program and the only UI is a somewhat odd shell, with no way to actually send input in or get output out. It gives the impression of a neat idea that is a cool academic toy but not a practical language for real-world use. I think that it would be helpful if more prolog intros had a simple example that read a CSV file or JSON object or something, processed it using the defined rules, and output the results to text or HTML file. That's a minor thing, but I think that it would give a better impression and get more people interested and trying it. Of course intros to other languages may gloss over I/O as well, but with mainstream imperative languages (that aren't oriented to defining and querying data), it's more well known or assumed that the standard I/O patterns apply.

white-flame 10y ago
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.
YeGoblynQueenne 10y ago
>> I think that it would be helpful if more prolog intros had a simple example that read a CSV file or JSON object or something, processed it using the defined rules, and output the results to text or HTML file. You're right about that and I don't think it's a minor thing. One reason is that most tutorials have a hard enough time going through everything you need to know before you can start parsing json and writing out to file, without getting stuck in infinite recursion etc. so the nitty-gritty of day-to-day programming work is often left as an exercise for the reader. On the other hand, I have the feeling that many people check out Prolog to see how it's different then go looking for the way to do the usual things in it. This may be the wrong approach. Prolog has some advanced features and those are "the whole point" about the language. If all you'll ever need to do is process some csv, there's probably no point in going through all the hard work to learn Prolog- you can do it in another language rather more easily. That said, the Swi-Prolog homepage has a link to a good tutorial on creating web applications with it that I recommend to anyone interested in that sort of thing: http://www.swi-prolog.org/ http://www.swi-prolog.org/ It's under the "Tutorials" header. Unfortunately my phone's ISP is blocking it so I can't link directly to it. Harumph.
- zmonx 10y ago
  Here's the link ("Prolog Web Applications"): https://www.metalevel.at/prolog/web.html https://www.metalevel.at/prolog/web.html
  - tom_mellior 10y ago
    That's just a short collection of resources, not a tutorial. The actual tutorial linked from http://www.swi-prolog.org/ http://www.swi-prolog.org/ -> Tutorials -> Web applications is http://www.pathwayslms.com/swipltuts/html/index.html http://www.pathwayslms.com/swipltuts/html/index.html
    - YeGoblynQueenne 10y ago
      Thanks. I'm supposed to call my ISP and tell them I'm over 18 to access the site, apparently. Can't even begin to fathom why the what.
user5994461 10y ago
That looks like the Haskell tutorials and trainings I've seen. At the end of it: 1) you didn't learn to read or write text to the console. 2) You are unable to make any useful program, let alone a hello world. This kind of non-practical training materials is a recurring issue with functional languages.
- tom_mellior 10y ago
  Well, it never claims to teach you all of the language; it tries to show off some neat parts. Articles like that often don't go into the details of I/O. Especially articles about languages with REPLs, which have much less need for that since they allow you to interact with your program more directly. (But it's true that many other Prolog resources also ignore I/O.)
- mickronome 10y ago
  That drives me up the wall too at times. It's a recurring theme when teaching languages to do it through something the author (maybe implicitly) consider a good fit, something that emphasise the beauty of that particular language. Might be good while you are learning your first language, maybe ? This explains the IO/side effect heavy imperative tutorials, the structure rich OO tutorials, the 'algorithmic' FP ones, etc. Turned upside down quite clearly tells you which language is strong in a particular area, and complicated/awkward in another. Myself, I prefer to start with the ugly parts, they contain much more information about the tradeoffs and focus of any particular language.

white-flame 10y ago

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.

YeGoblynQueenne 10y ago

>> I think that it would be helpful if more prolog intros had a simple example that read a CSV file or JSON object or something, processed it using the defined rules, and output the results to text or HTML file. You're right about that and I don't think it's a minor thing. One reason is that most tutorials have a hard enough time going through everything you need to know before you can start parsing json and writing out to file, without getting stuck in infinite recursion etc. so the nitty-gritty of day-to-day programming work is often left as an exercise for the reader. On the other hand, I have the feeling that many people check out Prolog to see how it's different then go looking for the way to do the usual things in it. This may be the wrong approach. Prolog has some advanced features and those are "the whole point" about the language. If all you'll ever need to do is process some csv, there's probably no point in going through all the hard work to learn Prolog- you can do it in another language rather more easily. That said, the Swi-Prolog homepage has a link to a good tutorial on creating web applications with it that I recommend to anyone interested in that sort of thing: http://www.swi-prolog.org/ http://www.swi-prolog.org/ It's under the "Tutorials" header. Unfortunately my phone's ISP is blocking it so I can't link directly to it. Harumph.

zmonx 10y ago
Here's the link ("Prolog Web Applications"): https://www.metalevel.at/prolog/web.html https://www.metalevel.at/prolog/web.html
- tom_mellior 10y ago
  That's just a short collection of resources, not a tutorial. The actual tutorial linked from http://www.swi-prolog.org/ http://www.swi-prolog.org/ -> Tutorials -> Web applications is http://www.pathwayslms.com/swipltuts/html/index.html http://www.pathwayslms.com/swipltuts/html/index.html
  - YeGoblynQueenne 10y ago
    Thanks. I'm supposed to call my ISP and tell them I'm over 18 to access the site, apparently. Can't even begin to fathom why the what.

user5994461 10y ago

That looks like the Haskell tutorials and trainings I've seen. At the end of it: 1) you didn't learn to read or write text to the console. 2) You are unable to make any useful program, let alone a hello world. This kind of non-practical training materials is a recurring issue with functional languages.

tom_mellior 10y ago
Well, it never claims to teach you all of the language; it tries to show off some neat parts. Articles like that often don't go into the details of I/O. Especially articles about languages with REPLs, which have much less need for that since they allow you to interact with your program more directly. (But it's true that many other Prolog resources also ignore I/O.)
mickronome 10y ago
That drives me up the wall too at times. It's a recurring theme when teaching languages to do it through something the author (maybe implicitly) consider a good fit, something that emphasise the beauty of that particular language. Might be good while you are learning your first language, maybe ? This explains the IO/side effect heavy imperative tutorials, the structure rich OO tutorials, the 'algorithmic' FP ones, etc. Turned upside down quite clearly tells you which language is strong in a particular area, and complicated/awkward in another. Myself, I prefer to start with the ugly parts, they contain much more information about the tradeoffs and focus of any particular language.