4 ms·

> 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. Th

• hnfong 4y ago
  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.
  • forgetfulness 4y ago
    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.
• logicmoo 4y ago
  -------- > 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.
• deleted 4y ago
  [deleted]
• logicmoo 4y ago
  > 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.