Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] Logic Programming in Perl -- Just say no

Expand Messages
  • Terrence Brannon
    ... How else are you going to solve the 8 queens problem? lol I guess I find it hard to see the practical use of logic programming. There is a dynamic logic
    Message 1 of 9 , Mar 31, 2005
    • 0 Attachment
      Rob Nagler <nagler@...> writes:

      > Curtis Poe writes:
      >
      >> My code currently only touches the full power of logic programming.

      > But what's it for? What problem are you trying to solve?
      >


      How else are you going to solve the 8 queens problem? lol
      I guess I find it hard to see the practical use of logic programming.

      There is a dynamic logic language written using 4 Haskell files :

      http://homepages.cwi.nl/~jve/dynamo/

      That shows how close Haskell is to the lambda calculus and predicate
      logic.



      --
      Carter's Compass: I know I'm on the right track when,
      by deleting something, I'm adding functionality.
    • Curtis Poe
      ... Rob, You just lost your case with that question. Most general purpose programming languages can solve any problem a Turing machine can solve. Contrary to
      Message 2 of 9 , Mar 31, 2005
      • 0 Attachment
        On Mar 30, 2005, at 9:44 PM, Rob Nagler wrote:
        > > My code currently only touches the full power of logic programming. 
        > > It doesn't allow modules, there are no definite clause grammars
        > (yet)
        > > and operator support is limited.  What does most of that mean?  Who
        > > knows?
        >
        > But what's it for?  What problem are you trying to solve?
        >
        > Rob

        Rob,

        You just lost your case with that question. Most general purpose
        programming languages can solve any problem a Turing machine can solve.
        Contrary to popular belief, Prolog can do just about anything Perl can
        do. Some things it can do better. Some things it can't. Those who
        don't have experience with different programming languages and
        paradigms often ask questions like "what's it for?" Hell, I remember
        asking that question when I first encountered OO.

        To answer your question: In Perl, you twist and munge your data until
        it eventually looks like your goal. With logic programming, you
        describe your goal in logical terms and the computer figures out how to
        twist and munge your data for you. As a result, logic programming is
        sometimes called "specification based" programming because with a
        well-thought out specification, you can translate it to Prolog and
        you're done (well, that's the theory, anyway).

        This leads easily to applications such as natural language processing,
        theorem proving, expert systems, inductive logic programming, etc.
        However, you can do CGI programming in Prolog if you want. You can use
        it to process text files. "What problem are you trying to solve" is a
        silly question in this context. I can solve any problem I reasonably
        need to. The question is, "what problems are better suited to Prolog?"
        No one's building theorem proving systems in Perl, to the best of my
        knowledge.

        (Side note: Prolog has some limitations and I'm not arguing that it's
        the best choice. If you're interested, I hear good things about
        Mercury)

        So, since you're so convinced that you really don't need to learn
        languages in other paradigms in order to understand them (you can learn
        all you want about France from the internet, right?), I have to ask:
        have you had any serious exposure to any of these languages? If so,
        which ones? (C and Java would be awful examples).

        Cheers,
        Ovid

        [Non-text portions of this message have been removed]
      • Rob Nagler
        ... http://www.symbolicdata.org/ Google is your friend: http://www.google.com/search?q=%22theorem+proving%22+perl ... This conversation isn t about me. I
        Message 3 of 9 , Mar 31, 2005
        • 0 Attachment
          Curtis Poe writes:
          > need to. The question is, "what problems are better suited to Prolog?"
          > No one's building theorem proving systems in Perl, to the best of my
          > knowledge.

          http://www.symbolicdata.org/

          Google is your friend:

          http://www.google.com/search?q=%22theorem+proving%22+perl

          > So, since you're so convinced that you really don't need to learn
          > languages in other paradigms in order to understand them (you can learn
          > all you want about France from the internet, right?), I have to ask:
          > have you had any serious exposure to any of these languages? If so,
          > which ones? (C and Java would be awful examples).

          This conversation isn't about me. I thought it was about how one
          becomes a better programmer. My thesis is that today, programmers
          should pick a multi-paradigm programming language, such as Python,
          Perl, Ruby, Lisp, etc. and work in a group that applies agile
          practices, in particular, extreme refactoring.

          A budding programmer should be able to realize when the pond she's
          programming in has grown too small and move on to a larger pond, i.e.,
          a company which has more experienced programmers. After 10 or 20
          years of this unglamorous regimen, our startlet will become a star if
          she has the raw talent and gumption.

          That's the recipe. If the programmer has to learn new tools along the
          way, they will add to her experience. It doesn't matter what the
          tools are. Sometimes it's mismatched tools like Eunice and other
          times it's cool operating systems like Linux. The important part is
          that the programmer sees her co-workers as peers and people from whom
          she can learn. They'll show her the cool bits in any of these tools,
          or explain how they would improve the tools if the boss would let them
          at it.

          Rob
        • Rob Kinyon
          ... So, programming is an apprenticeship-type career?
          Message 4 of 9 , Apr 1 4:52 AM
          • 0 Attachment
            > A budding programmer should be able to realize when the pond she's
            > programming in has grown too small and move on to a larger pond, i.e.,
            > a company which has more experienced programmers. After 10 or 20
            > years of this unglamorous regimen, our startlet will become a star if
            > she has the raw talent and gumption.

            So, programming is an apprenticeship-type career?
          • Rob Nagler
            ... Yes, imo. Most careers are, I would think. Rob
            Message 5 of 9 , Apr 1 7:49 AM
            • 0 Attachment
              Rob Kinyon writes:
              > So, programming is an apprenticeship-type career?

              Yes, imo. Most careers are, I would think.

              Rob
            • Curtis Poe
              ... Google better, please. They re building a system in Perl to manage data and benchmarks for symbolic computations, including theorem proving. They are not
              Message 6 of 9 , Apr 1 8:52 AM
              • 0 Attachment
                On Mar 31, 2005, at 10:28 PM, Rob Nagler wrote:

                > >   No one's building theorem proving systems in Perl, to the best of
                > my
                > > knowledge.
                >
                > http://www.symbolicdata.org/
                >
                > Google is your friend:
                >
                > http://www.google.com/search?q=%22theorem+proving%22+perl

                Google better, please. They're building a system in Perl to manage
                data and benchmarks for symbolic computations, including theorem
                proving. They are not doing theorem proving in Perl. I also found it
                interesting to note that several first page links for that query listed
                Prolog directly in the summary, despite you not searching for this
                term. Further, clicking on some of the links that don't list Prolog in
                the summary shows that Prolog is frequently used in this field, but
                Perl is traditionally used for collecting and summarizing the data.
                Fascinating how computer scientists are using different programming
                languages for their relative strengths rather than try to shoehorn
                everything into one language, eh?

                You're making an extraordinary claim and I'm asking what experience you
                have to back it up. You say that a person can achieve "X" by doing "Y"
                and that doing "Z" really isn't necessary. You haven't done Z, so you
                have no *personal* basis with which to compare. Many people (including
                myself) on this list who have done both Y and Z have direct personal
                experience and they disagree with you.

                Cheers,
                Ovid

                [Non-text portions of this message have been removed]
              • Rob Nagler
                ... Woops! http://groups.yahoo.com/group/theory-edge/message/9442 mentions a Turing Machine compiler written in Perl. Isn t this close enough? The point is
                Message 7 of 9 , Apr 1 1:45 PM
                • 0 Attachment
                  Curtis Poe writes:
                  > Google better, please. They're building a system in Perl to manage
                  > data and benchmarks for symbolic computations, including theorem

                  Woops!

                  http://groups.yahoo.com/group/theory-edge/message/9442

                  mentions a Turing Machine compiler written in Perl. Isn't this close
                  enough? The point is that you could do theorem proving in Perl. The
                  syntax does not have to be Prolog, and could be very Perl-like.

                  > languages for their relative strengths rather than try to shoehorn
                  > everything into one language, eh?

                  I never said people didn't use different languages. For example,
                  Python and Perl are quite similar. However, if you know Python, you
                  have all the tools and community you need to learn all the important
                  principles in computer science. If you come by them by someone making
                  a DSL that looks and smells like Prolog, you came about it through
                  your community. You don't need to learn Prolog separately. You get
                  he concepts, including how the language and interpreter are structured
                  through a package implemented in your own language. It's like
                  learning philosophy from translated versions of the originals. It's
                  still valid knowledge acquisition without leaving your native tongue.
                  You might bring in words such as Gestalt and Zeitgeist, but that's not
                  speaking or learning the language. Just a few important idioms
                  provided through the translation.

                  > You're making an extraordinary claim and I'm asking what experience you
                  > have to back it up. You say that a person can achieve "X" by doing "Y"
                  > and that doing "Z" really isn't necessary. You haven't done Z, so you
                  > have no *personal* basis with which to compare. Many people (including
                  > myself) on this list who have done both Y and Z have direct personal
                  > experience and they disagree with you.

                  There are a lot of interesting issues in the above paragraph. Trust
                  relationships are mathematical proofs based on axioms. Whatever I
                  write on this list is axiomatic. There is no way to prove or disprove
                  the claims. Complex trust delegations, such as, reputation, are based
                  on the ill-founded theory that the delegate is an appropriate
                  surrogate for your model of "doing". For example, most students who
                  have taken a comparative language course think they have "done" Lisp
                  and Smalltalk. BTW, this is why references and interviews are bad
                  predictors of future performance. It's too easy to lie, fool a
                  reference, or even collude with a reference.

                  Rob
                Your message has been successfully submitted and would be delivered to recipients shortly.