> 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.
--------
> 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.
If your aim is to develop an SAT solver, it is recommended to write it in Prolog.
For more general problem-solving, consider writing an SMT solver or another specialized solver (such as ILP) in Prolog, as it will likely be the most efficient choice.
In the case of creating type-safe software, writing the interpreter in Prolog is a good idea, as it allows for code verification during runtime.
Lastly, if you wish to integrate code and database functionality, it is advisable to use Prolog to develop an enhanced Datalog system, which will offer a more powerful and flexible solution.