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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.