16 ms·

Prolog Under the Hood: An Honest Look (1992)

60 points by networked 8y ago

carapace 8y ago
> After a brief exposure, however, many programmers fail to appreciate its full breadth and never use it again. Yeah. That was me. A friend of mine tried to clue me in to Prolog about twenty years ago and I didn't "get it". Recently I revisited it and realized that about 1/3 of my working career was wasted by not using Prolog. My strong suggestion to any programmers reading this: learn and use Prolog.
- chubot 8y ago
  Have you published any prolog code that demonstrates this? What domains are you working in? Programming is so diverse that I’m skeptical it applies to everyone, at least without further justification.
  - carapace 8y ago
    > Have you published any prolog code that demonstrates this? What domains are you working in? Yes, and functional language interpreter, specifically Joy[1]. I implemented a Joy interpreter in Python[2] and had just implemented type inference[3] and begun working towards a compiler when a paper went by here on HN about using Prolog to write compilers[4]. That initiated what I'm calling a "conversion experience" where I dug into Prolog and had the aforementioned epiphany. The crux came when, after reimplementing the Joy interpreter in just four lines of Prolog, I reimplemented the type inferencer and discovered that it was identical to the interpreter. [5] Two pages of Prolog code replaced about ten pages of Python code, and the resulting interpreter is more powerful and flexible than the previous implementation. > Programming is so diverse that I’m skeptical it applies to everyone, at least without further justification. There are a few non-Prolog-shaped domains, I'll grant you, but they are rare. I coined a new personal rule to the effect of "Use Prolog unless you absolutely can't." YMMV [1] https://en.wikipedia.org/wiki/Joy_(programming_language) https://en.wikipedia.org/wiki/Joy_(programming_language) http://www.kevinalbrecht.com/code/joy-mirror/joy.html http://www.kevinalbrecht.com/code/joy-mirror/joy.html [2] http://joypy.osdn.io/ http://joypy.osdn.io/ [3] http://joypy.osdn.io/notebooks/Types.html http://joypy.osdn.io/notebooks/Types.html [4] "Logic Programming and Compiler Writing" Warren 1980 https://www.researchgate.net/publication/220280364_Logic_Programming_and_Compiler_Writing https://www.researchgate.net/publication/220280364_Logic_Pro... https://news.ycombinator.com/item?id=17674859 https://news.ycombinator.com/item?id=17674859 [5] https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/thun.pl https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/... This is the published prolog code you asked for, compare to the Python implementation. https://osdn.net/projects/joypy/scm/hg/Joypy/tree/tip/joy/ https://osdn.net/projects/joypy/scm/hg/Joypy/tree/tip/joy/
    - naasking 8y ago
      Have you tried any other logic languages, like Mercury?
      - carapace 8y ago
        Not yet. "I am just an egg." :-)
    - chubot 8y ago
      Thanks for the links! I have two replies for this: (1) I would like to implement a type inferencer in Prolog and (2) This doesn't justify what you originally said (but we don't have to argue that point. I appreciate the response. :) ) ----- (1) Can you elaborate on what you mean by the type inferencer being identical to the interpreter? I see the type inferencer in Python in joy/utils/types.py. And I see your interpreter in Prolog -- but how does that do type inference? Why am I interested in type inference? I wrote a shell interpreter in 19K lines of Python: http://www.oilshell.org/release/0.6.pre8/metrics.wwz/line-counts/src.txt http://www.oilshell.org/release/0.6.pre8/metrics.wwz/line-co... (scroll to the end for line count) I want to compile it to faster code, and that likely involves type inference in the style of PyPy or ShedSkin (which are both used in production). Background: http://www.oilshell.org/blog/2018/03/04.html http://www.oilshell.org/blog/2018/03/04.html My understanding is that global type inference for 19K lines of code might be out of reach in terms of speed? As far as I know type inference algorithms are exponential in the worst case. While I'm using a relatively small subset of Python, the type system may still be considered rich (classes with single inheritance, __call__, varargs, perhaps typed dictionaries.) Do you think Prolog is feasible for this problem? Does it offer you help in terms of debugging and performance problems? Maybe I need some syntax for explicit annotation so I can "help" the backtracking succeed? I am not exactly sure how it will work. But doing it in Prolog seems somewhat appealing, if I can "prototype" the type system. Though there is the practical problem of simply getting the types into Prolog and back out. I think I would have to generate a prolog program with at least one clause for every variable in my 19K line interpreter? In any case, thanks for the links to your code. I will be looking at these further. ----- (2) A recent comment from someone with considerable expertise says that backtracking search just doesn't come up that often: https://www.reddit.com/r/ProgrammingLanguages/comments/9kb9z5/logic_programming_languages/ https://www.reddit.com/r/ProgrammingLanguages/comments/9kb9z... I seem to recall that Paul didn't just work with Mercury -- he worked on it -- and his Ph.D. work shows that: https://paul.bone.id.au/ https://paul.bone.id.au/ I think type inference is a great example of where it DOES come up. But very few people implement type systems (and production type checkers are often in imperative languages like TypeScript, or occasionally OCaml with Hack). Various types of scheduling may be another place, but I would also count that as a very small proportion of programming work. Not to mention games, network programming, kernels, etc. I believe you're wildly overstating the applicability of Prolog. A program might have small subproblems that could be expressed in Prolog, but the entire program doesn't fit that paradigm. Also, I also asked in that Reddit thread for "production" uses of Prolog, and I don't really see it. Erlang moved away from it for "engineering reasons", and they were one of the biggest advocates (I read Joe Armstrong's paper about prototyping Erlang in Prolog). Rust is maybe moving toward it, but they're probably using their own implementation and not an off-the-shelf Prolog interpreter. I think Prolog ironically falls in the category as Forth (and Joy is not even as practical as Forth). It's incredibly expressive for some things, and it has generated many epiphanies. But if you try to use it in production, you eventually "fall off a cliff" for parts of the program that don't fit the model. I experimented with both Forth and Joy a number of years ago, and have Manfred von Thun's papers printed out, sitting on my bookshelf. The quadratic formula was one small example of things that are awkward in stack languages, but I think there are others on a larger, architectural scale that are "dealbreakers". The conclusion I came to about Forth/Joy was that they're worth learning but there's a reason they aren't used much in production. I will probably end feeling the same way about logic programming (like Paul does after 10 years of deep experience), but I still want to learn it for the reasons everyone says.
- hderms 8y ago
  Recommendations if you're on be JVM primarily?
- marcell 8y ago
  Can you give one or two examples of where prolog would be more effective than other tools? I was exposed to it in college but never used it beyond that.
  - carapace 8y ago
    Sure! DCG (Definite Clause Grammar)[1] are similar to the OMeta PEG parsers[2] but more powerful and flexible. Constraint logic programming, e.g. CLP(FD)[3] makes many kinds of problem easy to solve. I wrote what I call the "Boring Sudoku Solver"[4] It's so simple it's dull. It'll solve, validate, and generate Sudoku puzzles. Interestingly, both of these are considered somewhat newfangled in the Prolog community (despite being ancient by, say, JS standards.) [1] https://en.wikipedia.org/wiki/Definite_clause_grammar https://en.wikipedia.org/wiki/Definite_clause_grammar http://www.amzi.com/manuals/amzi/pro/ref_dcg.htm http://www.amzi.com/manuals/amzi/pro/ref_dcg.htm https://www.metalevel.at/prolog/dcg https://www.metalevel.at/prolog/dcg http://www.pathwayslms.com/swipltuts/dcg/ http://www.pathwayslms.com/swipltuts/dcg/ [2] http://www.vpri.org/pdf/tr2007003_ometa.pdf http://www.vpri.org/pdf/tr2007003_ometa.pdf [3] https://en.wikipedia.org/wiki/Constraint_logic_programming https://en.wikipedia.org/wiki/Constraint_logic_programming http://pathwayslms.com/swipltuts/clpfd/clpfd.html http://pathwayslms.com/swipltuts/clpfd/clpfd.html https://www.metalevel.at/prolog/clpfd https://www.metalevel.at/prolog/clpfd http://www.swi-prolog.org/man/clpfd.html http://www.swi-prolog.org/man/clpfd.html [4] https://swish.swi-prolog.org/p/Boring%20Sudoku.swinb https://swish.swi-prolog.org/p/Boring%20Sudoku.swinb
- sgt101 8y ago
  20 years ago : you are right. Although be warned, Prolog has some killer issues, principally the way that the knowledge base and search system works means that you will end up stirring fiddle factors (cut) into your logic program and at scale the brain boggling complexity of what is going on can lead to complete, sudden and irretrievable project failure. As in : it doesn't work, no one knows why, no one can fix it and no one has a plan that doesn't involve starting from the beginning and doing it differently. consider two programs Good prolog : on(a,b). on(b,c). above(X,Y) :- on(X,Y). above(X,Y) :- on(X,Z), above(Z,Y). ->above(a,c). You'll get TRUE (yay) a is above c ! GOOOOOOOD prolog. but now : on(a,b). on(b,c). above(X,Y) :- above(X,Z), on(Z,Y). above(X,Y) :- on(X,Y). -> above(a,c). ERROR: Out of local stack Exception: (1,675,220) above(a, _4808) ? BAD BAD BAD BAD prolog. Go to your room! ERROR: Out of local stack Exception: (1,675,220) above(a, _4808) ? Prolog gets stuck expanding the first search until it can't carry on. One line is out of order in the program and you are dead, and the problem is that you will not find that line until that question is asked, and when you find it (in a real example) it really is the devils own job to work out where the expansion is coming and how to fix it. But there you go - search based logic resolution, brought to you by 1970's computer architecture (small main store) and solvers. Note, not only is "it doesn't bloody work" an issue, but also (probably much worse) "it keeps hanging for five minutes". This inconsistency and problem is hard to replicate and very, very hard to debug. It's caused by an occasional big search happening in the knowledge base, but a big search that doesn't end up exploding the system, it's often accompanied by shifty developer behaviour involving parameters and special cases. In a real project it's a nightmare. Now : NOOOOOOO! Instead use Problog or something similar and reason using Answer Sets. For your first steps an answer set system looks very like Prolog, but does not suffer from the issues above (as far as I can see). There has not been (so far) a big charge to use this in prod (with Prolog and KBS's there was, it failed, because above) because everyone is playing with 40 layer 200 billion parameter neural networks and wondering why proving they can beat a tiny part of one benchmark or mostly steer a car without killing many people is not translating into application success. And this is a good thing because I don't think that the tech is quite there yet and the community needs five years and about half a dozen big "let's make this practical" applied research projects (btw. keen on partners?) to actually make this manageable for people with deadlines and investors. But - it's going to help you more than Prolog.
- YeGoblynQueenne 8y ago
  >> Yeah. That was me. A friend of mine tried to clue me in to Prolog about twenty years ago and I didn't "get it". If it helps, I remember a senior programmer of mine once saying that out of 35 people in his Master's class, nobody really got it. It's the way that Prolog is taught at uni. I think, because there is so much material to cover and it's very hard to know where to start, most courses end up teaching whatever the tutors think are the most important bits. Most end up teaching it as any other language, starting from the syntax and going to examples of "how to do such-and-such in Prolog" - like, how to loop over a list etc. That is how I learned Prolog myself and it took me, I don't know, ten years? Before I could really get about half of what was going on. I think a much better approach would be to start with the theory of logic programming- spent two or three courses covering propositional and first order logic, then Horn clauses, subsumption and resolution, then when the students have at least a general idea of what logic programming is all about, get started with Prolog- which, after all, is just one possible logic programming language. Cover what it does best, what compromises it makes and what is good and bad about it. Instill some enthusiasm in the language. It's a really brilliant piece of theory and engineering and there's very good historical reasons why it is the way it is, the good and the bad, and the ugly. >> My strong suggestion to any programmers reading this: learn and use Prolog. Absolutely. Even more so- learn logic, and logic programming. Its impact on the way you code and the way you think is going to be huge. Hugely positive, that is.
  - carapace 8y ago
    I was literally hanging out with Doug Miles in a cafe in Seattle in the late 90's. I feel like an idiot in hindsight. He was so patient with me and I must have let him down. Oh well, the penny has dropped, and better late than never. I think you're right. I suspect that it would be easier (and likely advantageous) to teach predicate logic first and then introduce Prolog as a kind of straightforward calculator for it, than to teach people imperative programming and then teach them Prolog from that context. I will say that it's really weird to go from being a Python expert to a Prolog tyro, but you couldn't pay me enough to go back now. > It's a really brilliant piece of theory and engineering and there's very good historical reasons why it is the way it is, the good and the bad, and the ugly. Absolutely! Part of the fun has been learning about the rich history and all the research and implementations that have been done.
kirillzubovsky 8y ago
Writing Prolog was one of my favorite things in college. It's not the language that appealed to me, but the underlying ability to express and validate logic. It's so clean and delightful. I do wish more people would get introduced to logic this way, it's a very powerful instrument for everyday life.
sifoobar 8y ago
I think the real problem is that it's a lot more convenient to add logic capabilities to whatever language than to squeeze the entire solution into Prolog's limited view of the world. I know there are extensions and whatnots to build database driven GUI's and web apps in Prolog, but everything I've seen looks like one step to the side and two backwards. Possible does not imply useful. If it was such a great idea, plenty of people would already be doing it by now.
- ghosthamlet 8y ago
  I think you are Partly right, but Logic programming is very useful and elegant for some thing, like this static code analyzer for Clojure built by core.logic: https://github.com/jonase/kibit https://github.com/jonase/kibit
deleted 8y ago
[deleted]
YeGoblynQueenne 8y ago
>> Although Prolog's original intent was to allow programmers to specify programs in a syntax close to logic, that is not how Prolog works. In fact, a conceptual understanding of logic is not that useful for understanding Prolog. Look, I get what the article is saying, but the fact of the matter is that Prolog has to run on real-world computers and those are not purely logical. They have working memories and storage, they have processors that take in instructions one-by-one and so on. It's all nice and well to say that you want a purely declarative language but, well, we just don't have the hardware for that sort of thing, at least not yet anyway (and not in the foreseeable future, given that nobody is really working on that- not anymore, not after the Fifth Generation Computer programme tanked). So compromises have to be made. They have to be made at every step of the way. Compromises like the selection rule for resolvents (this is what makes the order of clauses in your program matter, when it doesn't in pure logic). Compromises like having extra-logical predicates, like write/1 and get/1 (the latter gets the next byte from the current input- what is a "byte" in logical terms? It isn't). Compromises like the cut, !/0 and even that stupid fail/0, that give you some control over the interpreter's program flow, which in and of itself is something completely outside of logic. But, this is how you get a language that is 90% of the way to the purely declartive, logic programming ideal. You gotta be, whatsitcalled, pragmatic, innit. I also don't agree that teaching the operational semantics of the language (the four-port model) is the best way to reveal the beauty of the language. I've been coding in Prolog since around 2008, and I was very comfortable with that model, but my understanding is still incomplete. I've recently read "Foundations of Inductive Logic Programming" that has a big intro to logic and logic programming with endless proofs about subsumption and the soundness of resolution and so on, and it's like, I was blind in one eye and could only see half the world. You gotta have a very solid grasp of both the theory and the practice to code well in Prolog. ... and there's your problem, right there. The investment you have to make to really master the language is huge and very few people have the resources for it.
- AlexCoventry 8y ago
  > The investment you have to make to really master the language is huge What's the payoff?
tralarpa 8y ago
(The last time I worked on a Prolog program was 20 years ago. It had only around 4000 lines, so take the following with a grain of salt.) For me, a work day in Prolog looked like this: Write your idea down in 1 hour and then spend the remaining 7 hours figuring out where to place the cuts :)
- marmaduke 8y ago
  Sometimes I think my Python code has 7 lines of validation or plumbing for each line of algorithm.
  - jgalt212 8y ago
    not far from the truth, but I guess it comes down to where to you place the technical debt (up front with statically typed langues), or after you have something working (dynamic languages). I favor the later because of the low cost of experimentation, but you do need get around to hardening the system, and that part has real costs.
    - taeric 8y ago
      While i agree with the technical debt here, I think you slightly misplace it. You take debt by using the libraries available on python. Same as you take loans from others that have capital. The currency here is their knowledge. That is, the dynamic/static divide is a distraction. Easy to talk towards, but likely nowhere near as important as other factors.
    - marmaduke 8y ago
      It has nothing to do with technical debt or typing but that input data could violate assumptions of the algorithm. Duck typing and Python large ecosystem does tend to exacerbate that though

60 points by networked 8y ago

> After a brief exposure, however, many programmers fail to appreciate its full breadth and never use it again. Yeah. That was me. A friend of mine tried to clue me in to Prolog about twenty years ago and I didn't "get it". Recently I revisited it and realized that about 1/3 of my working career was wasted by not using Prolog. My strong suggestion to any programmers reading this: learn and use Prolog.

chubot 8y ago
Have you published any prolog code that demonstrates this? What domains are you working in? Programming is so diverse that I’m skeptical it applies to everyone, at least without further justification.
- carapace 8y ago
  > Have you published any prolog code that demonstrates this? What domains are you working in? Yes, and functional language interpreter, specifically Joy[1]. I implemented a Joy interpreter in Python[2] and had just implemented type inference[3] and begun working towards a compiler when a paper went by here on HN about using Prolog to write compilers[4]. That initiated what I'm calling a "conversion experience" where I dug into Prolog and had the aforementioned epiphany. The crux came when, after reimplementing the Joy interpreter in just four lines of Prolog, I reimplemented the type inferencer and discovered that it was identical to the interpreter. [5] Two pages of Prolog code replaced about ten pages of Python code, and the resulting interpreter is more powerful and flexible than the previous implementation. > Programming is so diverse that I’m skeptical it applies to everyone, at least without further justification. There are a few non-Prolog-shaped domains, I'll grant you, but they are rare. I coined a new personal rule to the effect of "Use Prolog unless you absolutely can't." YMMV [1] https://en.wikipedia.org/wiki/Joy_(programming_language) https://en.wikipedia.org/wiki/Joy_(programming_language) http://www.kevinalbrecht.com/code/joy-mirror/joy.html http://www.kevinalbrecht.com/code/joy-mirror/joy.html [2] http://joypy.osdn.io/ http://joypy.osdn.io/ [3] http://joypy.osdn.io/notebooks/Types.html http://joypy.osdn.io/notebooks/Types.html [4] "Logic Programming and Compiler Writing" Warren 1980 https://www.researchgate.net/publication/220280364_Logic_Programming_and_Compiler_Writing https://www.researchgate.net/publication/220280364_Logic_Pro... https://news.ycombinator.com/item?id=17674859 https://news.ycombinator.com/item?id=17674859 [5] https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/thun.pl https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/... This is the published prolog code you asked for, compare to the Python implementation. https://osdn.net/projects/joypy/scm/hg/Joypy/tree/tip/joy/ https://osdn.net/projects/joypy/scm/hg/Joypy/tree/tip/joy/
  - naasking 8y ago
    Have you tried any other logic languages, like Mercury?
    - carapace 8y ago
      Not yet. "I am just an egg." :-)
  - chubot 8y ago
    Thanks for the links! I have two replies for this: (1) I would like to implement a type inferencer in Prolog and (2) This doesn't justify what you originally said (but we don't have to argue that point. I appreciate the response. :) ) ----- (1) Can you elaborate on what you mean by the type inferencer being identical to the interpreter? I see the type inferencer in Python in joy/utils/types.py. And I see your interpreter in Prolog -- but how does that do type inference? Why am I interested in type inference? I wrote a shell interpreter in 19K lines of Python: http://www.oilshell.org/release/0.6.pre8/metrics.wwz/line-counts/src.txt http://www.oilshell.org/release/0.6.pre8/metrics.wwz/line-co... (scroll to the end for line count) I want to compile it to faster code, and that likely involves type inference in the style of PyPy or ShedSkin (which are both used in production). Background: http://www.oilshell.org/blog/2018/03/04.html http://www.oilshell.org/blog/2018/03/04.html My understanding is that global type inference for 19K lines of code might be out of reach in terms of speed? As far as I know type inference algorithms are exponential in the worst case. While I'm using a relatively small subset of Python, the type system may still be considered rich (classes with single inheritance, __call__, varargs, perhaps typed dictionaries.) Do you think Prolog is feasible for this problem? Does it offer you help in terms of debugging and performance problems? Maybe I need some syntax for explicit annotation so I can "help" the backtracking succeed? I am not exactly sure how it will work. But doing it in Prolog seems somewhat appealing, if I can "prototype" the type system. Though there is the practical problem of simply getting the types into Prolog and back out. I think I would have to generate a prolog program with at least one clause for every variable in my 19K line interpreter? In any case, thanks for the links to your code. I will be looking at these further. ----- (2) A recent comment from someone with considerable expertise says that backtracking search just doesn't come up that often: https://www.reddit.com/r/ProgrammingLanguages/comments/9kb9z5/logic_programming_languages/ https://www.reddit.com/r/ProgrammingLanguages/comments/9kb9z... I seem to recall that Paul didn't just work with Mercury -- he worked on it -- and his Ph.D. work shows that: https://paul.bone.id.au/ https://paul.bone.id.au/ I think type inference is a great example of where it DOES come up. But very few people implement type systems (and production type checkers are often in imperative languages like TypeScript, or occasionally OCaml with Hack). Various types of scheduling may be another place, but I would also count that as a very small proportion of programming work. Not to mention games, network programming, kernels, etc. I believe you're wildly overstating the applicability of Prolog. A program might have small subproblems that could be expressed in Prolog, but the entire program doesn't fit that paradigm. Also, I also asked in that Reddit thread for "production" uses of Prolog, and I don't really see it. Erlang moved away from it for "engineering reasons", and they were one of the biggest advocates (I read Joe Armstrong's paper about prototyping Erlang in Prolog). Rust is maybe moving toward it, but they're probably using their own implementation and not an off-the-shelf Prolog interpreter. I think Prolog ironically falls in the category as Forth (and Joy is not even as practical as Forth). It's incredibly expressive for some things, and it has generated many epiphanies. But if you try to use it in production, you eventually "fall off a cliff" for parts of the program that don't fit the model. I experimented with both Forth and Joy a number of years ago, and have Manfred von Thun's papers printed out, sitting on my bookshelf. The quadratic formula was one small example of things that are awkward in stack languages, but I think there are others on a larger, architectural scale that are "dealbreakers". The conclusion I came to about Forth/Joy was that they're worth learning but there's a reason they aren't used much in production. I will probably end feeling the same way about logic programming (like Paul does after 10 years of deep experience), but I still want to learn it for the reasons everyone says.
hderms 8y ago
Recommendations if you're on be JVM primarily?
marcell 8y ago
Can you give one or two examples of where prolog would be more effective than other tools? I was exposed to it in college but never used it beyond that.
- carapace 8y ago
  Sure! DCG (Definite Clause Grammar)[1] are similar to the OMeta PEG parsers[2] but more powerful and flexible. Constraint logic programming, e.g. CLP(FD)[3] makes many kinds of problem easy to solve. I wrote what I call the "Boring Sudoku Solver"[4] It's so simple it's dull. It'll solve, validate, and generate Sudoku puzzles. Interestingly, both of these are considered somewhat newfangled in the Prolog community (despite being ancient by, say, JS standards.) [1] https://en.wikipedia.org/wiki/Definite_clause_grammar https://en.wikipedia.org/wiki/Definite_clause_grammar http://www.amzi.com/manuals/amzi/pro/ref_dcg.htm http://www.amzi.com/manuals/amzi/pro/ref_dcg.htm https://www.metalevel.at/prolog/dcg https://www.metalevel.at/prolog/dcg http://www.pathwayslms.com/swipltuts/dcg/ http://www.pathwayslms.com/swipltuts/dcg/ [2] http://www.vpri.org/pdf/tr2007003_ometa.pdf http://www.vpri.org/pdf/tr2007003_ometa.pdf [3] https://en.wikipedia.org/wiki/Constraint_logic_programming https://en.wikipedia.org/wiki/Constraint_logic_programming http://pathwayslms.com/swipltuts/clpfd/clpfd.html http://pathwayslms.com/swipltuts/clpfd/clpfd.html https://www.metalevel.at/prolog/clpfd https://www.metalevel.at/prolog/clpfd http://www.swi-prolog.org/man/clpfd.html http://www.swi-prolog.org/man/clpfd.html [4] https://swish.swi-prolog.org/p/Boring%20Sudoku.swinb https://swish.swi-prolog.org/p/Boring%20Sudoku.swinb
sgt101 8y ago
20 years ago : you are right. Although be warned, Prolog has some killer issues, principally the way that the knowledge base and search system works means that you will end up stirring fiddle factors (cut) into your logic program and at scale the brain boggling complexity of what is going on can lead to complete, sudden and irretrievable project failure. As in : it doesn't work, no one knows why, no one can fix it and no one has a plan that doesn't involve starting from the beginning and doing it differently. consider two programs Good prolog : on(a,b). on(b,c). above(X,Y) :- on(X,Y). above(X,Y) :- on(X,Z), above(Z,Y). ->above(a,c). You'll get TRUE (yay) a is above c ! GOOOOOOOD prolog. but now : on(a,b). on(b,c). above(X,Y) :- above(X,Z), on(Z,Y). above(X,Y) :- on(X,Y). -> above(a,c). ERROR: Out of local stack Exception: (1,675,220) above(a, _4808) ? BAD BAD BAD BAD prolog. Go to your room! ERROR: Out of local stack Exception: (1,675,220) above(a, _4808) ? Prolog gets stuck expanding the first search until it can't carry on. One line is out of order in the program and you are dead, and the problem is that you will not find that line until that question is asked, and when you find it (in a real example) it really is the devils own job to work out where the expansion is coming and how to fix it. But there you go - search based logic resolution, brought to you by 1970's computer architecture (small main store) and solvers. Note, not only is "it doesn't bloody work" an issue, but also (probably much worse) "it keeps hanging for five minutes". This inconsistency and problem is hard to replicate and very, very hard to debug. It's caused by an occasional big search happening in the knowledge base, but a big search that doesn't end up exploding the system, it's often accompanied by shifty developer behaviour involving parameters and special cases. In a real project it's a nightmare. Now : NOOOOOOO! Instead use Problog or something similar and reason using Answer Sets. For your first steps an answer set system looks very like Prolog, but does not suffer from the issues above (as far as I can see). There has not been (so far) a big charge to use this in prod (with Prolog and KBS's there was, it failed, because above) because everyone is playing with 40 layer 200 billion parameter neural networks and wondering why proving they can beat a tiny part of one benchmark or mostly steer a car without killing many people is not translating into application success. And this is a good thing because I don't think that the tech is quite there yet and the community needs five years and about half a dozen big "let's make this practical" applied research projects (btw. keen on partners?) to actually make this manageable for people with deadlines and investors. But - it's going to help you more than Prolog.
YeGoblynQueenne 8y ago
>> Yeah. That was me. A friend of mine tried to clue me in to Prolog about twenty years ago and I didn't "get it". If it helps, I remember a senior programmer of mine once saying that out of 35 people in his Master's class, nobody really got it. It's the way that Prolog is taught at uni. I think, because there is so much material to cover and it's very hard to know where to start, most courses end up teaching whatever the tutors think are the most important bits. Most end up teaching it as any other language, starting from the syntax and going to examples of "how to do such-and-such in Prolog" - like, how to loop over a list etc. That is how I learned Prolog myself and it took me, I don't know, ten years? Before I could really get about half of what was going on. I think a much better approach would be to start with the theory of logic programming- spent two or three courses covering propositional and first order logic, then Horn clauses, subsumption and resolution, then when the students have at least a general idea of what logic programming is all about, get started with Prolog- which, after all, is just one possible logic programming language. Cover what it does best, what compromises it makes and what is good and bad about it. Instill some enthusiasm in the language. It's a really brilliant piece of theory and engineering and there's very good historical reasons why it is the way it is, the good and the bad, and the ugly. >> My strong suggestion to any programmers reading this: learn and use Prolog. Absolutely. Even more so- learn logic, and logic programming. Its impact on the way you code and the way you think is going to be huge. Hugely positive, that is.
- carapace 8y ago
  I was literally hanging out with Doug Miles in a cafe in Seattle in the late 90's. I feel like an idiot in hindsight. He was so patient with me and I must have let him down. Oh well, the penny has dropped, and better late than never. I think you're right. I suspect that it would be easier (and likely advantageous) to teach predicate logic first and then introduce Prolog as a kind of straightforward calculator for it, than to teach people imperative programming and then teach them Prolog from that context. I will say that it's really weird to go from being a Python expert to a Prolog tyro, but you couldn't pay me enough to go back now. > It's a really brilliant piece of theory and engineering and there's very good historical reasons why it is the way it is, the good and the bad, and the ugly. Absolutely! Part of the fun has been learning about the rich history and all the research and implementations that have been done.

kirillzubovsky 8y ago

Writing Prolog was one of my favorite things in college. It's not the language that appealed to me, but the underlying ability to express and validate logic. It's so clean and delightful. I do wish more people would get introduced to logic this way, it's a very powerful instrument for everyday life.

sifoobar 8y ago

I think the real problem is that it's a lot more convenient to add logic capabilities to whatever language than to squeeze the entire solution into Prolog's limited view of the world. I know there are extensions and whatnots to build database driven GUI's and web apps in Prolog, but everything I've seen looks like one step to the side and two backwards. Possible does not imply useful. If it was such a great idea, plenty of people would already be doing it by now.

ghosthamlet 8y ago
I think you are Partly right, but Logic programming is very useful and elegant for some thing, like this static code analyzer for Clojure built by core.logic: https://github.com/jonase/kibit https://github.com/jonase/kibit

deleted 8y ago

[deleted]

YeGoblynQueenne 8y ago

>> Although Prolog's original intent was to allow programmers to specify programs in a syntax close to logic, that is not how Prolog works. In fact, a conceptual understanding of logic is not that useful for understanding Prolog. Look, I get what the article is saying, but the fact of the matter is that Prolog has to run on real-world computers and those are not purely logical. They have working memories and storage, they have processors that take in instructions one-by-one and so on. It's all nice and well to say that you want a purely declarative language but, well, we just don't have the hardware for that sort of thing, at least not yet anyway (and not in the foreseeable future, given that nobody is really working on that- not anymore, not after the Fifth Generation Computer programme tanked). So compromises have to be made. They have to be made at every step of the way. Compromises like the selection rule for resolvents (this is what makes the order of clauses in your program matter, when it doesn't in pure logic). Compromises like having extra-logical predicates, like write/1 and get/1 (the latter gets the next byte from the current input- what is a "byte" in logical terms? It isn't). Compromises like the cut, !/0 and even that stupid fail/0, that give you some control over the interpreter's program flow, which in and of itself is something completely outside of logic. But, this is how you get a language that is 90% of the way to the purely declartive, logic programming ideal. You gotta be, whatsitcalled, pragmatic, innit. I also don't agree that teaching the operational semantics of the language (the four-port model) is the best way to reveal the beauty of the language. I've been coding in Prolog since around 2008, and I was very comfortable with that model, but my understanding is still incomplete. I've recently read "Foundations of Inductive Logic Programming" that has a big intro to logic and logic programming with endless proofs about subsumption and the soundness of resolution and so on, and it's like, I was blind in one eye and could only see half the world. You gotta have a very solid grasp of both the theory and the practice to code well in Prolog. ... and there's your problem, right there. The investment you have to make to really master the language is huge and very few people have the resources for it.

AlexCoventry 8y ago
> The investment you have to make to really master the language is huge What's the payoff?

tralarpa 8y ago

(The last time I worked on a Prolog program was 20 years ago. It had only around 4000 lines, so take the following with a grain of salt.) For me, a work day in Prolog looked like this: Write your idea down in 1 hour and then spend the remaining 7 hours figuring out where to place the cuts :)

marmaduke 8y ago
Sometimes I think my Python code has 7 lines of validation or plumbing for each line of algorithm.
- jgalt212 8y ago
  not far from the truth, but I guess it comes down to where to you place the technical debt (up front with statically typed langues), or after you have something working (dynamic languages). I favor the later because of the low cost of experimentation, but you do need get around to hardening the system, and that part has real costs.
  - taeric 8y ago
    While i agree with the technical debt here, I think you slightly misplace it. You take debt by using the libraries available on python. Same as you take loans from others that have capital. The currency here is their knowledge. That is, the dynamic/static divide is a distraction. Easy to talk towards, but likely nowhere near as important as other factors.
  - marmaduke 8y ago
    It has nothing to do with technical debt or typing but that input data could violate assumptions of the algorithm. Duck typing and Python large ecosystem does tend to exacerbate that though