10 ms·

I think Prolog's main problem is that it presents the idea of "just declare the constraints and it will find the solution," but can't really live up to that. In

I think Prolog's main problem is that it presents the idea of "just declare the constraints and it will find the solution," but can't really live up to that. In reality it's an extremely leaky abstraction, and even with pure predicates you need to take its execution model into account to avoid getting stuck in an infinite loop. I still love the language, but I think there's a point where every learner realizes it's not as beautiful and ideal as they once thought.

usgroup 3y ago
I recently read “Simply Logical” —- it makes very clear that you have to take Prolog’s execution model into account from Chapter 3 onwards. You really don’t have to go far in Prolog before you have to write a meta interpreter and think about search strategies. I think this is in plain sight from the beginning.
- infogulch 3y ago
  Sure, nobody is deceived by the reality of the execution engine. But it's hard not to see a pure statement that is fast in one mode but slow in a different mode, determined entirely by the logically arbitrary order of two clauses, and not wish that the computer could just figure out those details itself.
  - hnfong 3y ago
    I just replied to https://news.ycombinator.com/item?id=35625640 https://news.ycombinator.com/item?id=35625640 and I am inclined to believe that someone is deceived…
felixyz 3y ago
The fact that you need to understand the execution model is not a limitation or an accident: it's a feature. One of the aims of prolog is to PROgram in logic. There are plenty of other logical frameworks that you can use to formulate a problem, make deductions etc, but then what do you do? The point of Prolog is that the operational and declarative semantics concur (excuse the non-exact verbiage). People mistakenly think this means there shouldn't be an operational semantics, or that it's a failure if you have to learn about it. If that's what you need, Answer Set Programming (or SMT solvers etc) might be a better fit. But that's not what Prolog is aiming to be.
- usgroup 3y ago
  I’m not sure it’s a feature that you MUST think about the execution model even for trivial things :-) but that you can and should is certainly a strength.
  - felixyz 3y ago
    It's really not different from any other programming language, I think Prolog is just held to a higher standard, and I think that might be due to a misconception. Also, XSB Prolog and SLG resolution[1] should be mentioned. It solves some of the problems with Prolog that force you to think about the execution model when you'd rather not. To some extent, this can be thought of as getting the good parts of both Datalog and Prolog. SLG resolution was introduced in SWI-Prolog as well fairly recently[2]. [1]: https://www3.cs.stonybrook.edu/~sbprolog/manual1/node2.html https://www3.cs.stonybrook.edu/~sbprolog/manual1/node2.html [2]: https://www.swi-prolog.org/pldoc/man?section=tabling https://www.swi-prolog.org/pldoc/man?section=tabling
- ghusbands 3y ago
  Just try writing (without hacks/cuts) a run-length encoder that produces only one answer ([9,9,9,8,8,7] -> [[9,3], [8,2], [7,1]]) and works forwards and backwards and then tell me the execution model is not a limitation. It's the sort of thing where people produce versions that seem to work, but fall into infinite loops or inconsistent extra outputs if you go past the first answer. I'm not sure it's actually possible without meta-programming.
  - convolvatron 3y ago
    I think aggregates help here by allowing you to take one answer, or take the best. But in general absolutely
  - YeGoblynQueenne 3y ago
    >> Just try writing (without hacks/cuts) a run-length encoder that produces only one answer ([9,9,9,8,8,7] -> [[9,3], [8,2], [7,1]]) and works forwards and backwards and then tell me the execution model is not a limitation. But, why not use the cut? It's a feature of the language and it's there exactly so you don't have to bust your head trying to find a way to do things the hard way. I honestly don't understand what's the fuss with the poor cut. If you want an efficient language that runs on a computer then you have to be pragmatic and recognise that concessions have to be made to accommodate the limitations of the hardware. If you want something pure and ideal, then you should probably not be trying to do that on a computer. You should probably not be trying to do it at all. There are no pure formal systems, or if there are, we can't explain or understand them because they can't communicate with the external world (hey, no side effects, OK?). See Haskell, for instance. The article above says something really strange about Haskell, that it: >> ... finally broke through the wall of pure-functional programs being seen as ivory-tower languages that were impractical, or at least really awkward, for any system that needed to do I/O or interact with users Which to me is insane. I think it's talking about monads. Monads, as an escape from the ivory tower, impractical, or at least awkward formalisms of... what, LISP? I mean for the love of dogs. Prolog is a balanced language. People complain about it because it's not unbalanced, that's the problem. If it were 100% declarative and nobody could program anything in it, it would have legions of dotting admirers praising it for its perfection, and whining because they have to do all their work in languages that are hardly 10% declarative, like Rust, or Python or Ruby (and I'm being generous). People have to get their head around this: our computer science is primitive and it is full of holes, dark pits of despair and undecidability, intractability, and terminal inefficiency. To be practical, a language has to give up a little part of its true, pure self, that it could achieve in a perfect world. So Prolog has the cut, and you can use it to control its backtracking, which you need because it's implemented as a depth-first search, because that's efficient and convenient. So use the cut, it's a feature.
yuretz 3y ago
This is the case with any other declarative programming system: while you only care about "what", i.e. the end result matching your declarative specification, you are living a dream. Once you need to fine-tune the details of how you get there (e.g. performance, resource use), or tweak the end result in a way that is not easy to describe within the constraints of your declarative dream land, things get ugly pretty quickly. Query hints in some SQL dialects, vendor-specific hacks in HTML/CSS, Kubernetes YAML templating, etc. are all sad stories about it.
- nightowl_games 3y ago
  Can you elaborate on the flaws of Kubernetes YAML templating? Can you include a description of a better system?
  - infogulch 3y ago
    CUE https://cuelang.org/ https://cuelang.org/
  - yuretz 3y ago
    Sure. Using things like loops and conditionals to stitch parts of the specification together is not a very declarative way to do things, imo. Regarding a better system I don't know, they all have their quirks, I guess. My point was that purely declarative approach has its limits and often times breaks when facing real world complexity.
  - ekimekim 3y ago
    Using a template to render out text that is then interpreted as something else (YAML in this case) is always fraught with quoting issues, complex workarounds, and for YAML specifically indentation issues. You see the same thing with the C preprocessor - there's a very good reason that basically no language since has copied that design, and it's infamous for being full of footguns. A far simpler and more manageable solution is to generate the same data structure (the final manifest) in a language which can actually represent those data structures directly. That might be a dedicated language like Cue or Jsonnet, or it could just be a general purpose programming language. You can generate the data structure using whatever tools you like, and then render it to JSON or YAML to be consumed by whatever tool is uploading it to kubernetes (kubectl apply, helm, etc).
time_to_smile 3y ago
I fully agree and came here to post something very similar. Advanced (or even non-trivial) prolog requires such a deep understanding of what prolog is doing under the hood that, at that point, you should be able to implement whatever you're trying to solve just as easily in your favorite non-prolog programming language. What makes this problem really bad is that everything about your problem that isn't directly related to logic programming is much harder to do in pure prolog. Just reading in a list of facts from a CSV file is non-trivial in prolog. In the end Prolog makes trivial but hard problems easy, while non-trivial hard problems remain hard to solve, and easy problems, even some trivial ones, also remain hard. I still love Prolog as well because it really does change the way you think about programming, but it is very far from even Haskell in allowing you to extend these new ways of thinking to solving real world problems.
- superdisk 3y ago
  Well said. Although there are a few things Prolog excels at, grammars are one of which. DCGs are one of my favorite things about any language ever and I miss them everywhere else.

usgroup 3y ago

I recently read “Simply Logical” —- it makes very clear that you have to take Prolog’s execution model into account from Chapter 3 onwards. You really don’t have to go far in Prolog before you have to write a meta interpreter and think about search strategies. I think this is in plain sight from the beginning.

infogulch 3y ago
Sure, nobody is deceived by the reality of the execution engine. But it's hard not to see a pure statement that is fast in one mode but slow in a different mode, determined entirely by the logically arbitrary order of two clauses, and not wish that the computer could just figure out those details itself.
- hnfong 3y ago
  I just replied to https://news.ycombinator.com/item?id=35625640 https://news.ycombinator.com/item?id=35625640 and I am inclined to believe that someone is deceived…

felixyz 3y ago

The fact that you need to understand the execution model is not a limitation or an accident: it's a feature. One of the aims of prolog is to PROgram in logic. There are plenty of other logical frameworks that you can use to formulate a problem, make deductions etc, but then what do you do? The point of Prolog is that the operational and declarative semantics concur (excuse the non-exact verbiage). People mistakenly think this means there shouldn't be an operational semantics, or that it's a failure if you have to learn about it. If that's what you need, Answer Set Programming (or SMT solvers etc) might be a better fit. But that's not what Prolog is aiming to be.

usgroup 3y ago
I’m not sure it’s a feature that you MUST think about the execution model even for trivial things :-) but that you can and should is certainly a strength.
- felixyz 3y ago
  It's really not different from any other programming language, I think Prolog is just held to a higher standard, and I think that might be due to a misconception. Also, XSB Prolog and SLG resolution[1] should be mentioned. It solves some of the problems with Prolog that force you to think about the execution model when you'd rather not. To some extent, this can be thought of as getting the good parts of both Datalog and Prolog. SLG resolution was introduced in SWI-Prolog as well fairly recently[2]. [1]: https://www3.cs.stonybrook.edu/~sbprolog/manual1/node2.html https://www3.cs.stonybrook.edu/~sbprolog/manual1/node2.html [2]: https://www.swi-prolog.org/pldoc/man?section=tabling https://www.swi-prolog.org/pldoc/man?section=tabling
ghusbands 3y ago
Just try writing (without hacks/cuts) a run-length encoder that produces only one answer ([9,9,9,8,8,7] -> [[9,3], [8,2], [7,1]]) and works forwards and backwards and then tell me the execution model is not a limitation. It's the sort of thing where people produce versions that seem to work, but fall into infinite loops or inconsistent extra outputs if you go past the first answer. I'm not sure it's actually possible without meta-programming.
- convolvatron 3y ago
  I think aggregates help here by allowing you to take one answer, or take the best. But in general absolutely
- YeGoblynQueenne 3y ago
  >> Just try writing (without hacks/cuts) a run-length encoder that produces only one answer ([9,9,9,8,8,7] -> [[9,3], [8,2], [7,1]]) and works forwards and backwards and then tell me the execution model is not a limitation. But, why not use the cut? It's a feature of the language and it's there exactly so you don't have to bust your head trying to find a way to do things the hard way. I honestly don't understand what's the fuss with the poor cut. If you want an efficient language that runs on a computer then you have to be pragmatic and recognise that concessions have to be made to accommodate the limitations of the hardware. If you want something pure and ideal, then you should probably not be trying to do that on a computer. You should probably not be trying to do it at all. There are no pure formal systems, or if there are, we can't explain or understand them because they can't communicate with the external world (hey, no side effects, OK?). See Haskell, for instance. The article above says something really strange about Haskell, that it: >> ... finally broke through the wall of pure-functional programs being seen as ivory-tower languages that were impractical, or at least really awkward, for any system that needed to do I/O or interact with users Which to me is insane. I think it's talking about monads. Monads, as an escape from the ivory tower, impractical, or at least awkward formalisms of... what, LISP? I mean for the love of dogs. Prolog is a balanced language. People complain about it because it's not unbalanced, that's the problem. If it were 100% declarative and nobody could program anything in it, it would have legions of dotting admirers praising it for its perfection, and whining because they have to do all their work in languages that are hardly 10% declarative, like Rust, or Python or Ruby (and I'm being generous). People have to get their head around this: our computer science is primitive and it is full of holes, dark pits of despair and undecidability, intractability, and terminal inefficiency. To be practical, a language has to give up a little part of its true, pure self, that it could achieve in a perfect world. So Prolog has the cut, and you can use it to control its backtracking, which you need because it's implemented as a depth-first search, because that's efficient and convenient. So use the cut, it's a feature.

yuretz 3y ago

This is the case with any other declarative programming system: while you only care about "what", i.e. the end result matching your declarative specification, you are living a dream. Once you need to fine-tune the details of how you get there (e.g. performance, resource use), or tweak the end result in a way that is not easy to describe within the constraints of your declarative dream land, things get ugly pretty quickly. Query hints in some SQL dialects, vendor-specific hacks in HTML/CSS, Kubernetes YAML templating, etc. are all sad stories about it.

nightowl_games 3y ago
Can you elaborate on the flaws of Kubernetes YAML templating? Can you include a description of a better system?
- infogulch 3y ago
  CUE https://cuelang.org/ https://cuelang.org/
- yuretz 3y ago
  Sure. Using things like loops and conditionals to stitch parts of the specification together is not a very declarative way to do things, imo. Regarding a better system I don't know, they all have their quirks, I guess. My point was that purely declarative approach has its limits and often times breaks when facing real world complexity.
- ekimekim 3y ago
  Using a template to render out text that is then interpreted as something else (YAML in this case) is always fraught with quoting issues, complex workarounds, and for YAML specifically indentation issues. You see the same thing with the C preprocessor - there's a very good reason that basically no language since has copied that design, and it's infamous for being full of footguns. A far simpler and more manageable solution is to generate the same data structure (the final manifest) in a language which can actually represent those data structures directly. That might be a dedicated language like Cue or Jsonnet, or it could just be a general purpose programming language. You can generate the data structure using whatever tools you like, and then render it to JSON or YAML to be consumed by whatever tool is uploading it to kubernetes (kubectl apply, helm, etc).

time_to_smile 3y ago

I fully agree and came here to post something very similar. Advanced (or even non-trivial) prolog requires such a deep understanding of what prolog is doing under the hood that, at that point, you should be able to implement whatever you're trying to solve just as easily in your favorite non-prolog programming language. What makes this problem really bad is that everything about your problem that isn't directly related to logic programming is much harder to do in pure prolog. Just reading in a list of facts from a CSV file is non-trivial in prolog. In the end Prolog makes trivial but hard problems easy, while non-trivial hard problems remain hard to solve, and easy problems, even some trivial ones, also remain hard. I still love Prolog as well because it really does change the way you think about programming, but it is very far from even Haskell in allowing you to extend these new ways of thinking to solving real world problems.

superdisk 3y ago
Well said. Although there are a few things Prolog excels at, grammars are one of which. DCGs are one of my favorite things about any language ever and I miss them everywhere else.