I don’t think those are the problems since all sorts of solvers ship with prolog and it’s still a better way to write down a problem.
I think it’s biggest headwind is that you have to be significantly more intelligent than the average developer to think in Prolog.
Prolog requires you to think about code as the implication of constraints — you just have to keep a lot more in your head. Prolog also requires you to understand the execution model before you can do much of anything.
> I think it’s biggest headwind is that you have to be significantly more intelligent than the average developer to think in Prolog.
This is arguably wrong. Thinking in Prolog is much easier than knowing how to solve a problem beforehand. In Prolog you just state the facts and known rules, but you have no clear idea what would be the best way to solve it. Prolog solves it for you then, if possible. No intelligence needed. A "dumb" friend of mine on the 80ies only used Prolog for his work and was very happy with it. Lisp, Pascal or C was too hard for him.
The problem with Prolog is mostly that you'll through too hard problems at it, mostly with exponential complexity. Tiny changes have huge influences then, it either works or not.
Also the tabling and SAT/SMT integration sucks.
The problem with your claims is that once you start “debugging”, it gets complicated quickly.
You’ll have to gain an intuition of how the language actually tries so solve the problem under the hood.
sometimes the problem you encounter doesn’t match the capabilities of the language, and then you’ll have to state the problem in a roundabout way to coax the language to do what you intended.
It’s probably great for the small number of toy problems that it was designed to solve, but in my limited experience prolog doesn’t do well on real world problems that have all sorts of edge cases and dirty inputs.
You see this often in the data side of things, we delegate very laborious or very complicated tasks to powerful the powerful engines behind Postgres, BigQuery, Spark, and the like, and while they provide you with a high level interface that make common tasks very convenient, mastery can take years as you have to study the architecture and implementation behind them.
It's a huge investment on your end to do that, and people do it readily because the return is being able to process datasets of sizes and complexity that you otherwise wouldn't be able to.
People haven't found it to be a good investment in their time to commit themselves to Prolog's engine.
--------
> Thinking in Prolog is much easier than knowing how to solve a problem beforehand. In Prolog you just state the facts and known rules, but you have no clear idea what would be the best way to solve it.
While Prolog streamlines certain aspects of problem-solving due to its declarative nature, it still necessitates a clear understanding of the desired solution and the proper organization of facts and rules. Although Prolog's approach abstracts some implementation details, a well-planned strategy remains essential.
--------
> No intelligence needed.
Prolog might make some tasks seem simpler, but intelligence and a deep comprehension of logic programming are still needed to efficiently create and maintain solutions.
--------
> A "dumb" friend of mine on the 80ies only used Prolog for his work and was very happy with it. Lisp, Pascal or C was too hard for him.
I may be the "dumb" friend you referred to?
Consider this: someone skilled in producing valuable software using Prolog is likely knowledgeable and proficient enough to program professionally in various other languages, such as C, Lisp, C#, C++, Scala, Java, Pascal, Python, Assembly, and more.
As an experienced programmer with a strong background in multiple languages, I often receive requests to translate my Prolog software into languages like Python, Java, or C#. However, I usually decline and claim that "it would be too hard"
--------
> The problem with Prolog is mostly that you'll throw too hard problems at it, mostly with exponential complexity.
Prolog isn't inherently prone to exponential complexity problems. The complexity depends on the problem being solved and how the facts and rules are structured.
It's crucial to understand the problem domain and optimize the Prolog code accordingly
The complexity of a problem and fluid nature of flow control shifts during software runtime often make it unfeasible to implement the software in alternative languages. So consequently, in the rare instances when I or others have attempted this, we have either developed or found a Prolog interpreter in the target language and executed the original code.
Had these tasks not been so daunting, others would have already implemented solutions to them in different languages, and there would be no need for people to continually request my assistance!
--------
> Tiny changes have huge influences then, it either works or not.
While it is true that small changes can sometimes have significant impacts on the behavior of a Prolog program, this is not unique to Prolog. Any programming language can experience similar issues if the underlying logic is not well-designed or properly tested. It is the developer's responsibility to understand the problem domain and design the logic appropriately to avoid unintended consequences.
--------
> Also the tabling and SAT/SMT integration sucks.
Tabling is a technique used in Prolog to store intermediate results of a computation to avoid redundant sub-computations, thus improving the efficiency of certain types of queries. While it may have some limitations, it is generally considered a valuable feature of Prolog that can enhance performance for specific types of problems.
Prolog's integration with SAT (Boolean Satisfiability) and SMT (Satisfiability Modulo Theories) solvers is not inherently flawed. Prolog can be used effectively in combination with these solvers to tackle complex problems in various domains. Integrating Prolog with these solvers might require a good understanding of the solver's functionality and the problem domain, but the same can be said for integrating any other programming language with these solvers. It's important to leverage the latest Prolog tools and libraries to optimize these aspects of your program.
> Thinking in Prolog is much easier than knowing how to solve a problem beforehand. In Prolog you just state
> the facts and known rules, but you have no clear idea what would be the best way to solve it.
>
Prolog is a programming language that takes a unique approach to problem-solving due to its declarative
nature. While this can simplify certain aspects, it is important to have a solid understanding of the problem
you are trying to solve and how to properly organize the facts and rules. Even though Prolog can abstract
some of the implementation details away, having a well-thought-out plan and strategy is still necessary to
effectively use the language.
>
> No intelligence needed.
>
Although Prolog might make some tasks appear more straightforward, it is important to remember that
intelligence and a comprehensive understanding of logic programming are still required to efficiently create
and maintain solutions within the language.
>
> A "dumb" friend of mine in the 80s only used Prolog for his work and was very happy with it. Lisp, Pascal or C
> was too hard for him.
>
I may be the "dumb" friend you referred to?
Consider this: someone skilled in producing valuable software using Prolog is likely knowledgeable and
proficient enough to program professionally in various other languages, such as C, Lisp, C#, C++, Scala, Java,
Pascal, Python, Assembly, and more.
As an experienced programmer with a strong background in multiple languages, I often receive requests to
translate my Prolog software into languages like Python, Java, or C#. However, I usually decline and claim
that "it would be too hard"
Had these tasks not been so daunting, others would have already implemented solutions to them in
different languages, and there would be no need for people to continually request my assistance!
>
> The problem with Prolog is mostly that you'll throw too hard problems at it, mostly with exponential complexity.
>
Prolog is not inherently more susceptible to problems with exponential complexity than other programming
languages. The complexity of a problem depends on the specific problem being addressed and how the facts
and rules are organized within the Prolog code. To optimize Prolog code, it is essential to have a deep
understanding of the problem domain and to structure the code in a way that minimizes complexity.
>
> Tiny changes have huge influences then, it either works or not.
>
It is true that small changes in a program can sometimes have a significant impact on its behavior. This is
not a characteristic unique to Prolog; it can happen in any programming language if the underlying logic is
not well-designed or properly tested. It is the responsibility of the developer to understand the problem domain
and design the logic in such a way that it avoids unintended consequences, regardless of the programming
language used.
>
> Also the tabling and SAT/SMT integration sucks.
>
Tabling is a technique in Prolog that stores intermediate results of a computation to prevent redundant
sub-computations, thereby improving the efficiency of certain types of queries. Although it may have some
limitations, tabling is generally considered a valuable feature of Prolog that can enhance performance for
specific types of problems.
Prolog's integration with SAT (Boolean Satisfiability) and SMT (Satisfiability Modulo Theories) solvers is
not inherently flawed. Prolog can be used effectively in combination with these solvers to tackle complex
problems in various domains. Integrating Prolog with these solvers might require a good understanding of
the solver's functionality and the problem domain, but the same can be said for integrating any other programming
language with these solvers. It's important to leverage the latest Prolog tools and libraries to optimize these
aspects of your program.
> Prolog also requires you to understand the execution model before you can do much of anything.
This is true of most (all?) languages. Prolog's control flow is ultimately not too different from the usual stack-based semantics people are used to from imperative languages like C (if you're not too ambitious with the backtracking; if you are, best of luck!). The tricky part is perhaps understanding the dataflow that arises from unification. That can be arbitrarily complex but it seems people tend to go no further than difference structures, which are easy to comprehend in terms of pointers. (Yes yes I know, but logic variables are essentially just single-assignment pointers.)
The thing I find deeply weird about the logic programming literature is that if you want to reason about your program you're told to use things like Hoare logic [1] or intended interpretations [2] and not fundamental logical concepts like implementations implying specifications (ala Lamport and many others who grappled with refinement).
Well no, I’d go as far as to say that your average JS/Python dev will know very little about how their code is executed — and doesn’t need to know necessarily. SQL on the other hand is a different story . Noobs don’t know , but pros know and consider the execution graph of a query.
You don’t really have a choice in Prolog —- gotta know what the interpreter is doing from the beginning otherwise you can’t debug.
I don't disagree with your stance but one of the most beautiful things to come from this line of work was Ehud Shapiro's declarative debugging [1]. I'd recommend taking a look at his PhD thesis if you're at all interested in what logic programming can do (that nothing else can [2]). You can also see it as a philosophical exercise: he shows how we might understand Popper's falsification criterion and use it to do science.
[2] There have been attempts to build declarative debuggers for other languages but for one reason or another (complexity, space use, incomplete coverage of the language, ...) they don't appear to get used very widely. Shapiro's setup is beautifully simple for what it does.
Here "declarative" means that you have a model in mind ("model" in the sense of logic, i.e., you expect your predicates to hold of particular arguments) and the tool helps you explore the divergence between what you wrote and what you intended. Thinking this way means you can completely ignore the details of SLD-NF resolution (the details of the Prolog implementation)... I mean, it's unlikely to be perfect in practice for any number of reasons, but I find it very disappointing that we don't dream like this any more.
It't just that everyone has the execution model of imperative languages so internalized, we mostly don't think about it. Same with OO semantics, not to mention various JS pitfalls - they are second nature to enough people that they count as nature-given, but one false move and they come back to bite you.
It’s worth pointing out that the semantics of prodcedural programs tend to be pairwise, while coaxing the prolog solver to terminate is a more global, transitive problem
I disagree. A JS/Python developer will have no problem understanding the following example, which makes absolutely no sense without some (operational) semantic model of the code:
Prolog solvers don't necessarily optimize like gurobi, cplex or OR-tools would. Yes they can give you a solution that satisfies the constraints, and you can query for more possible answers, but it doesn't really optimize for the objective function in the same way.
I think it’s biggest headwind is that you have to be significantly more intelligent than the average developer to think in Prolog.
Prolog requires you to think about code as the implication of constraints — you just have to keep a lot more in your head. Prolog also requires you to understand the execution model before you can do much of anything.