5 ms·

This is something that unfortunately doesn't have a straightforward answer. Prolog ended up being very influential, but its very nature meant it was never going

This is something that unfortunately doesn't have a straightforward answer. Prolog ended up being very influential, but its very nature meant it was never going to become mainstream. Prolog was intended to be a way to program using logic. It did this in a way by encoding facts in a manner not dissimilar to a relational database; logical statements about the world that resembled functions using Horn clauses (which you can think of as mathematical functions, but applied to logic); and unification, which is what links all this together. Unification is computation via the idea that you have a set of data, a bunch of logical statements, and you want to find everything in the data that satisfies those logical statement. If you know SQL, Horn clauses should sound a lot like materialised views. As to why it never really went mainstream, it's a matter of wrong place, wrong time. It didn't help that the language needed a checkpointing mechanism (referred to as 'cuts', and represented by '!') because the unification mechanism could get confused and do much more work than it needed to, so developers needed to put cuts in place to tell the interpreter where it could avoid backtracking to try more solutions within a Horn clause. If you want to get a taste for it, maybe give this a try: https://github.com/norswap/prolog-dry https://github.com/norswap/prolog-dry Prolog is one of a small number of languages that people should learn even if they never use it in a practical way.

YeGoblynQueenne 6y ago
>> As to why it never really went mainstream, it's a matter of wrong place, wrong time. It didn't help that the language needed a checkpointing mechanism (referred to as 'cuts', and represented by '!') because the unification mechanism could get confused and do much more work than it needed to, so developers needed to put cuts in place to tell the interpreter where it could avoid backtracking to try more solutions within a Horn clause. Prolog backtracks when there are more solutions to a goal (think of a goal as a query). Not because "unification gets confused". Unification doesn't have anything to do with backtracking, rather backtracking is a mechanism to represent the natural nondeterminism of logic theories, where multiple variable instantiations ("bindings") might satisfy a formula. So, when you enter a query at the Prolgo top-level (the console) Prolog will try to find a set of variable bindings that refute your query in the context of your loaded program. If it can, it will report "false", i.e. the query cannot be satisfied in the context of the program. If it can't, it will report "true", i.e. the query can be satisfied in the context of the program and it will also report the variable bindings that make the query true. If there are more than one sets of bindings that make the query true, you can ask for more solutions. At that point Prolog will backtrack and give you more solutions. However, there is nothing forcing your program to be written so as to produce multiple solutions to a query. It's entirely up to you and how you write your program. You can write a program so that it's deterministic (succeeds or fails exactly once) or not. The cut (!/0) is one way to force a program to become deterministic, but again that's not because anything gets confused. It's because sometimes it's hard to write a program so as for it to be deterministic. And sometimes you just have no idea why your program backtracks and you pepper your code with cuts, hoping it will stop. Which of course happens less and less as you get to understand how the language works (and why it's a bad idea to put cuts everywhere in the first place). (It's a bad idea because it means you don't understand how your own program works. Nine times out of ten you don't need to use it when you think you do). (But I still use the cut all the bloody time because it's convenient).
- talideon 6y ago
  > Not because "unification gets confused". I know that, and I know the difference between a red and a green cut. However, I was targeting my explanation towards somebody who is completely unfamiliar with the language.
  - YeGoblynQueenne 6y ago
    But, saying that "the unification mechanism could get confused" and that developers "needed" to use the cuts to control it makes it sound like backtracking is somehow wrong or unwanted, or a defect in the language. This risks confusing someone who is unfamiliar with the language.

YeGoblynQueenne 6y ago

>> As to why it never really went mainstream, it's a matter of wrong place, wrong time. It didn't help that the language needed a checkpointing mechanism (referred to as 'cuts', and represented by '!') because the unification mechanism could get confused and do much more work than it needed to, so developers needed to put cuts in place to tell the interpreter where it could avoid backtracking to try more solutions within a Horn clause. Prolog backtracks when there are more solutions to a goal (think of a goal as a query). Not because "unification gets confused". Unification doesn't have anything to do with backtracking, rather backtracking is a mechanism to represent the natural nondeterminism of logic theories, where multiple variable instantiations ("bindings") might satisfy a formula. So, when you enter a query at the Prolgo top-level (the console) Prolog will try to find a set of variable bindings that refute your query in the context of your loaded program. If it can, it will report "false", i.e. the query cannot be satisfied in the context of the program. If it can't, it will report "true", i.e. the query can be satisfied in the context of the program and it will also report the variable bindings that make the query true. If there are more than one sets of bindings that make the query true, you can ask for more solutions. At that point Prolog will backtrack and give you more solutions. However, there is nothing forcing your program to be written so as to produce multiple solutions to a query. It's entirely up to you and how you write your program. You can write a program so that it's deterministic (succeeds or fails exactly once) or not. The cut (!/0) is one way to force a program to become deterministic, but again that's not because anything gets confused. It's because sometimes it's hard to write a program so as for it to be deterministic. And sometimes you just have no idea why your program backtracks and you pepper your code with cuts, hoping it will stop. Which of course happens less and less as you get to understand how the language works (and why it's a bad idea to put cuts everywhere in the first place). (It's a bad idea because it means you don't understand how your own program works. Nine times out of ten you don't need to use it when you think you do). (But I still use the cut all the bloody time because it's convenient).

talideon 6y ago
> Not because "unification gets confused". I know that, and I know the difference between a red and a green cut. However, I was targeting my explanation towards somebody who is completely unfamiliar with the language.
- YeGoblynQueenne 6y ago
  But, saying that "the unification mechanism could get confused" and that developers "needed" to use the cuts to control it makes it sound like backtracking is somehow wrong or unwanted, or a defect in the language. This risks confusing someone who is unfamiliar with the language.