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

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

Expand Messages
  • 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 1 of 9 , Mar 31, 2005
      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 2 of 9 , Mar 31, 2005
        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 3 of 9 , Apr 1, 2005
          > 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 4 of 9 , Apr 1, 2005
            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 5 of 9 , Apr 1, 2005
              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 6 of 9 , Apr 1, 2005
                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.