4 ms·

Is Prolog really used for medical-system software? It seems to me that it turned out to be the wrong path taken by Japan's Fifth Generation Project. In the ear

by todd8 8y ago

Is Prolog really used for medical-system software? It seems to me that it turned out to be the wrong path taken by Japan's Fifth Generation Project. In the early 80's I experimented with Prolog. Simple ideas were simply coded into programs; it was really very interesting. However, the need to understand the compiler's inner workings to get programs that ran efficiently by manually inserting "cuts" to limit backtracking ruins Prolog's claim to being simple to translate requirements into programs. An even more serious problem with Prolog is the simplicity of it's model for logic. It is very easy to end up with requirements in the real world that don't easily fit the model. See for example the SHOOT problem in [1], where the concluding sentence is: > As such, the claim implicit in the development of nonmonotonic logics--that a simple extension to classical logic would result in the power to express an important class of human nondeductive reasoning--is certainly called into question by our result. Don't get me wrong, I was the Chief Scientist at a company with one Prolog based product. I still thinks its an interesting language, but I predict that it will remain eclipsed by much more general purpose programming languages. [1] https://www.aaai.org/Papers/AAAI/1986/AAAI86-054.pdf https://www.aaai.org/Papers/AAAI/1986/AAAI86-054.pdf

blobjectivism 8y ago
The popular narratives that 5th generation computing, expert systems, etc failed to deliver because it was the 'wrong path' to take is bs, basically the hardware designers weren't used to non-turing architectures, it was hard to find (and hire) programmers that fully understood both non-imperative paradigms and hardware integration, and government funded science (outside of black budget defense and intelligence projects) education and research started taking a nosedive during the 80s.
derefr 8y ago
It is! You don't use it for diagnosis; you use it to formalize treatment guidelines (which are effectively 'expert systems' even on paper.) It runs alongside more ML-based models, glued together under business-logic written in something like Java.
- YeGoblynQueenne 8y ago
  You have got to give more details about this :)
YeGoblynQueenne 8y ago
>> In the early 80's I experimented with Prolog. Simple ideas were simply coded into programs; it was really very interesting. However, the need to understand the compiler's inner workings to get programs that ran efficiently by manually inserting "cuts" to limit backtracking ruins Prolog's claim to being simple to translate requirements into programs. Where does this claim come from? Prolog is an automated theorem prover for first-order logic theories. There have certainly been various arguments about the pros and cons of it made by many different people (not all of whom were close to the development of the language), but the fact remains that its main characteristic is the automation of a proof process. You can certainly find many flaws in Prolog if you look hard enough and choose your requirements carefully (for example- it has no functions! Why has it no functions? It should have functions! Therefore, it sucks). I think a lot of the bad rep Prolog's got over the years is the result of promises by various sources that had nothing to do with its actual goal, which was to create a language with the syntax and semantics of FOL- which it achieves not perfectly, but way, way better than anything else out there. >> I still thinks its an interesting language, but I predict that it will remain eclipsed by much more general purpose programming languages. That's probably true, though :)
- todd8 8y ago
  Yes, thanks for the correction. You are right, it is possible to learn to Prolog without understanding the inner workings of the compiler or even the Warren Abstract Machine, but that is how I understood why I had to put up with the cut operator in my programs. I was originally sold on the idea of Prolog because of the many beautiful declarative examples found in introductory tutorials. The sad truth is that Prolog isn't magic and just like Functional Programming, Object-Oriented Programming, or even Structured Programming, there are wrinkles that one encounters that require a less than pure language semantics. In Prolog's case the semantics must be understood procedurally by understanding the order of goal searching and backtracking. From Clocksin and Mellish [1]: > So the moral is: If you introduce cuts to obtain correct behaviour when the goals are of one form, there is no guarantee that anything sensible will happen if goals of another form start appearing. It follows that it is only possible to use the cut reliably if you have a clear policy about how your rules are going to be used. If you change this policy, all uses of the cut must be reviewed. The cut operator in Prolog is used to make programs more efficient or to make the language more expressive[2]. So there is little alternative but to accept it's use along with it's confusing and error prone semantics due to it having a meaning that is only in terms of the procedural semantics of Prolog[3]. From Clause and Effect, section 4.3 titled "Taming Cut"[4]: > It is not easy to understand the full implications of using cut. Prolog looks like it allows programming by specifying what is wanted rather than by specifying how to get to what is wanted. This appearance might even be partly justified, and it is certainly touted by Prolog's promoters. From the preface to Prolog for Programmers[5]: > ... Prolog can be classified as a descriptive programming language, as opposed to prescriptive (or imperative) languages such as Pascal, C and Ada. In principle, the programmer is only supposed to specify what is to be done by his or her program, without bothering with how this should be achieved. ... In practice, however, Prolog can be treated as a procedural language. I think this is misleading. In my mind it should end with the sentence: In practice, Prolog must be treated as a procedural language in addition to a descriptive language. In their chapter devoted to cuts and negation, Sterling and Shapiro[6] say: > With ingenuity, and a good understanding of unification and the execution mechanism of Prolog, interesting definitions can be found for many meta-logical predicates. A sense of the necessary contortions can be found in the program for same_var(X,Y), ... This expects programmers to have a non-trivial understanding of Prolog's implementation. I was wrong to say that an understanding of the compiler was needed, but programmers do have to understand unification and the order of evaluation used by the language. Finally, I believe that the cut operator also makes parallel processing implementations of Prolog very difficult. In this post Moore's law era this will cause problems for Prolog's performance without making more of the implementation leak though to the language semantics. Logic and constraint programming are interesting techniques, and it's difficult to say where they will lead. Prolog is an important language in the history of programming languages. Perhaps Logic Programming will make a comeback aided by the new advances in automated theorem proving. [1] Clocksin, W. F. and Mellish, C. S. Programming in Prolog. Springer-Verlag, 1981. p. 78. [2] Bratko, Ivan. Prolog Programming for Artificial Intelligence. Addison-Wesley, 1986. p. 136. [3] Roger, Jean B. A Prolog Primer. Addison-Wesley, 1986. p. 115. [4] Clocksin, William F., Clause and Effect, Springer, 1997. p. 50. [5] Kluźniak, Feliks and Szpakowicz, Stanisław, Prolog for Programmers, Academic Press, 1985. p xi. [6] Sterling, Leon and Shapiro Ehud, The Art of Prolog, 2nd Ed. The MIT Press, 1994. p. 201.

by todd8 8y ago

blobjectivism 8y ago

The popular narratives that 5th generation computing, expert systems, etc failed to deliver because it was the 'wrong path' to take is bs, basically the hardware designers weren't used to non-turing architectures, it was hard to find (and hire) programmers that fully understood both non-imperative paradigms and hardware integration, and government funded science (outside of black budget defense and intelligence projects) education and research started taking a nosedive during the 80s.

derefr 8y ago

It is! You don't use it for diagnosis; you use it to formalize treatment guidelines (which are effectively 'expert systems' even on paper.) It runs alongside more ML-based models, glued together under business-logic written in something like Java.

YeGoblynQueenne 8y ago
You have got to give more details about this :)

YeGoblynQueenne 8y ago

>> In the early 80's I experimented with Prolog. Simple ideas were simply coded into programs; it was really very interesting. However, the need to understand the compiler's inner workings to get programs that ran efficiently by manually inserting "cuts" to limit backtracking ruins Prolog's claim to being simple to translate requirements into programs. Where does this claim come from? Prolog is an automated theorem prover for first-order logic theories. There have certainly been various arguments about the pros and cons of it made by many different people (not all of whom were close to the development of the language), but the fact remains that its main characteristic is the automation of a proof process. You can certainly find many flaws in Prolog if you look hard enough and choose your requirements carefully (for example- it has no functions! Why has it no functions? It should have functions! Therefore, it sucks). I think a lot of the bad rep Prolog's got over the years is the result of promises by various sources that had nothing to do with its actual goal, which was to create a language with the syntax and semantics of FOL- which it achieves not perfectly, but way, way better than anything else out there. >> I still thinks its an interesting language, but I predict that it will remain eclipsed by much more general purpose programming languages. That's probably true, though :)

todd8 8y ago
Yes, thanks for the correction. You are right, it is possible to learn to Prolog without understanding the inner workings of the compiler or even the Warren Abstract Machine, but that is how I understood why I had to put up with the cut operator in my programs. I was originally sold on the idea of Prolog because of the many beautiful declarative examples found in introductory tutorials. The sad truth is that Prolog isn't magic and just like Functional Programming, Object-Oriented Programming, or even Structured Programming, there are wrinkles that one encounters that require a less than pure language semantics. In Prolog's case the semantics must be understood procedurally by understanding the order of goal searching and backtracking. From Clocksin and Mellish [1]: > So the moral is: If you introduce cuts to obtain correct behaviour when the goals are of one form, there is no guarantee that anything sensible will happen if goals of another form start appearing. It follows that it is only possible to use the cut reliably if you have a clear policy about how your rules are going to be used. If you change this policy, all uses of the cut must be reviewed. The cut operator in Prolog is used to make programs more efficient or to make the language more expressive[2]. So there is little alternative but to accept it's use along with it's confusing and error prone semantics due to it having a meaning that is only in terms of the procedural semantics of Prolog[3]. From Clause and Effect, section 4.3 titled "Taming Cut"[4]: > It is not easy to understand the full implications of using cut. Prolog looks like it allows programming by specifying what is wanted rather than by specifying how to get to what is wanted. This appearance might even be partly justified, and it is certainly touted by Prolog's promoters. From the preface to Prolog for Programmers[5]: > ... Prolog can be classified as a descriptive programming language, as opposed to prescriptive (or imperative) languages such as Pascal, C and Ada. In principle, the programmer is only supposed to specify what is to be done by his or her program, without bothering with how this should be achieved. ... In practice, however, Prolog can be treated as a procedural language. I think this is misleading. In my mind it should end with the sentence: In practice, Prolog must be treated as a procedural language in addition to a descriptive language. In their chapter devoted to cuts and negation, Sterling and Shapiro[6] say: > With ingenuity, and a good understanding of unification and the execution mechanism of Prolog, interesting definitions can be found for many meta-logical predicates. A sense of the necessary contortions can be found in the program for same_var(X,Y), ... This expects programmers to have a non-trivial understanding of Prolog's implementation. I was wrong to say that an understanding of the compiler was needed, but programmers do have to understand unification and the order of evaluation used by the language. Finally, I believe that the cut operator also makes parallel processing implementations of Prolog very difficult. In this post Moore's law era this will cause problems for Prolog's performance without making more of the implementation leak though to the language semantics. Logic and constraint programming are interesting techniques, and it's difficult to say where they will lead. Prolog is an important language in the history of programming languages. Perhaps Logic Programming will make a comeback aided by the new advances in automated theorem proving. [1] Clocksin, W. F. and Mellish, C. S. Programming in Prolog. Springer-Verlag, 1981. p. 78. [2] Bratko, Ivan. Prolog Programming for Artificial Intelligence. Addison-Wesley, 1986. p. 136. [3] Roger, Jean B. A Prolog Primer. Addison-Wesley, 1986. p. 115. [4] Clocksin, William F., Clause and Effect, Springer, 1997. p. 50. [5] Kluźniak, Feliks and Szpakowicz, Stanisław, Prolog for Programmers, Academic Press, 1985. p xi. [6] Sterling, Leon and Shapiro Ehud, The Art of Prolog, 2nd Ed. The MIT Press, 1994. p. 201.