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

Logic Programming in Perl -- Just say no

Expand Messages
  • Curtis Poe
    Sorry for starting a new thread; I just joined this list. I was told about the thread regarding different paradigms of programming and how Perl allows one
    Message 1 of 9 , Mar 30, 2005
    • 0 Attachment
      Sorry for starting a new thread; I just joined this list. I was told
      about the thread regarding different paradigms of programming and how
      "Perl" allows one to handle many different and thus one doesn't need to
      learn other languages. Pulling out one quote from Rob Nagle from the
      thread:

      > Here's a bold statement: you don't really need to learn a new
      > programming language, if you know Perl. Perl allows you to think like
      > you would in Haskell, C, Java, Lisp, etc. You do need to learn all
      > that Perl offers, and that's where HOP fits in.

      Rob, I'm sorry, but this is completely wrong. It reminds of me of a
      kid in a writing class who explained to our prof that he doesn't need
      to visit foreign countries because he has the Internet. I didn't know
      whether to laugh or cry.

      Another example: I speak French. I don't speak it as well as I used
      to, but I can still hobble along a bit. As soon as I started learning
      French, my grades in English shot up quite a bit. Aside from some odd
      idiomatic constructs in both languages, there's little that can be
      expressed in one that can't be expressed in another, but that hardly
      suggests that learning French is a useless exercise.

      More examples: when I learned Java, my OO Perl knowledge and ability
      improved tremendously. There's not much in Java that I can't do in
      Perl (the reverse is not true, oddly enough), but even Java's "almost
      OO" implementation was tremendously useful.

      And then we get to Smalltalk. Take a gander at this code
      (http://squeak.org/tutorials/cphoenix_tutorial/intro.html):

      1. hello: times
      2. (times > 100)
      3. ifTrue: [ Transcript show: 'You will get bored!']
      4. ifFalse: [1 to: times do: [:i | (Transcript show: 'Hello
      World') cr]]

      (I added the line numbers)

      Line two is not a conditional. It's a constructor that returns a
      boolean object. Lines 3 and 4 are the "ifTrue" and "ifFalse" messages
      that are sent to the boolean instance. The object decides how to
      handle (and even ignore) those messages. There really aren't if/else
      statements in Smalltalk. And what does that mean for this argument?
      After I started thinking about that for a while and examining my OO
      code, many of my if/else statements were actually encapsulation
      violations. By rigorously excising them, my code became simple, more
      correct and easier to maintain. By diving into another programming
      culture, I learned more about my own.

      Maybe you can do without other programming languages for the bulk of
      your work, but you cannot replicate their culture in Perl. You cannot
      truly understand what it is to be French without living over there.
      Think of Java: so much Java code out there is merely procedural code
      wrapped in classes. There's nothing OO about it (and the same is true
      of many Perl OO modules). However, those who write that code are quite
      likely to claim they understand OO.

      So my subject was rather tongue-in-cheek, but it's not too far off.
      MMy 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? One will never know if one only goes by my code.

      Cheers,
      Ovid
    • Rob Nagler
      ... Code! Notice the bug? Here s a refactoring that eliminates redundancy and the bug: hello: times (times 100) ifTrue: [self print: You will get bored! ]
      Message 2 of 9 , Mar 30, 2005
      • 0 Attachment
        Curtis Poe writes:
        > 1. hello: times
        > 2. (times > 100)
        > 3. ifTrue: [ Transcript show: 'You will get bored!']
        > 4. ifFalse: [1 to: times do: [:i | (Transcript show: 'Hello World') cr]]

        Code! Notice the bug? Here's a refactoring that eliminates
        redundancy and the bug:

        hello: times
        (times > 100)
        ifTrue: [self print: 'You will get bored!']
        ifFalse: [times timesRepeat: [self print: 'Hello World')]];

        print: s
        Transcript show: s; cr

        I am not a Smalltalker, but I suspect there's a way to do this in
        Smalltalk:

        sub hello {
        my($times) = @_;
        print(STDOUT
        map("$_\n",
        $times > 100 ? 'You will get bored!'
        : map('Hello World', 1 .. $times),
        ),
        );
        }

        > 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
      • 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 3 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 4 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 5 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 6 of 9 , Apr 1, 2005
              • 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 7 of 9 , Apr 1, 2005
                • 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 8 of 9 , Apr 1, 2005
                  • 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 9 of 9 , Apr 1, 2005
                    • 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.