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

Re: [extremeperl] Terrence the Hypocrite

Expand Messages
  • Rob Kinyon
    ... I believe Knuth said it best when he wrote Beware of bugs in the above code; I have only proved it correct, not tried it. Functional programming allows
    Message 1 of 13 , Apr 3, 2005
    • 0 Attachment
      > Hypocrisy Two:
      > -------------
      >
      > After claiming that testing was irrelevant in Haskell, I am now at
      > Section 4.5 in the best Haskell instructional text I have seen, "Craft
      > of Functional Programming" by Thompson, and what is this chapter
      > called: "Program Testing". So, there we go. Two feet in my mouth in
      > less than 2 days.

      I believe Knuth said it best when he wrote "Beware of bugs in the
      above code; I have only proved it correct, not tried it." Functional
      programming allows for proofs. It doesn't mean that you didn't typo
      anything. Testing in such a situation is for making sure you typed

      twoExp n
      | n == 1 = 2
      | even n = (twoExp m) ** 2
      | odd n = 2 * (twoExp m) ** 2
      where m = n `quot` 2

      and didn't type

      twoExp n
      | n == 1 = 3
      | even n = (twoExp m) ** 2
      | odd n = 2 * (twoExp m) ** 2
      where m = n `quot` 2

      Rob
    • Adam Turoff
      ... I don t know about that. I find this version more readable: twoExp n ... where m = n `quot` 2 x = (twoExp m) ** 2 In the Forth world, the most important
      Message 2 of 13 , Apr 4, 2005
      • 0 Attachment
        On Apr 3, 2005 4:49 PM, Terrence Brannon <bauhaus@...> wrote:
        > Not two full days after I call for the head of Rob Nagler for leading
        > people into the heinous act of copying code, do I do it myself, albeit
        > in Haskell:
        >
        > twoExp n
        > | n == 1 = 2
        > | even n = (twoExp m) ** 2
        > | odd n = 2 * (twoExp m) ** 2
        > where m = n `quot` 2
        >
        > I did it because I felt that the expression:
        >
        > (twoExp m) ** 2
        >
        > was far more readable that abstracting it for "re-use"

        I don't know about that. I find this version more readable:

        twoExp n
        | n == 1 = 2
        | even n = x
        | odd n = 2 * x
        where m = n `quot` 2
        x = (twoExp m) ** 2

        In the Forth world, the most important tool a programmer needs is a
        thesaurus. If you can name a concept, you have identified it (_and_
        given it an identity -- a single implementation), and you can refer to
        it as necessary. This obviously works better when you can compose
        higher order operations from smaller ones. Don't try this with COBOL. ;-)

        I don't have a good name for the task you are trying to accomplish
        recursively, so I'm just using the name 'x' here. This should be named
        better, but (1) the scope is quite small (so a name like 'm' or 'x' does
        not require much in the way of disambiguation), and (2) it's a trivial
        refactoring that should take on the order of 30 seconds.

        The key here is to waste less time arguing over what and when to
        refactor, and just refactoring when you see a problem. (Provided you
        have a good test suite to prove your refactoring reasonably correct,
        and your refactorings take closer to 30 seconds than 30 days.)

        > After claiming that testing was irrelevant in Haskell, I am now at
        > Section 4.5 in the best Haskell instructional text I have seen, "Craft
        > of Functional Programming" by Thompson, and what is this chapter
        > called: "Program Testing". So, there we go. Two feet in my mouth in
        > less than 2 days.

        I think the more important point here is that your function is undefined
        for n <= 0. That's a pretty serious bug. It catches the case where n
        is non integral thanks to the type system though. ;-)


        Finally, I want to point out that this whole line of discussion has an
        angels-dancing-on-a-pin quality to it, and serves as proof by example
        of Torkington's Law[1].

        -- Adam

        [1] Email is a vast, global conspiracy to waste _your_ time.
      • Adrian Howard
        ... [snip] Not to mention those of us who now consider testing as a design practice which you need to do before you write code. Relevant no matter what
        Message 3 of 13 , Apr 7, 2005
        • 0 Attachment
          On 4 Apr 2005, at 02:07, Rob Kinyon wrote:

          >
          >> Hypocrisy Two:
          >> -------------
          >>
          >> After claiming that testing was irrelevant in Haskell, I am now at
          >> Section 4.5 in the best Haskell instructional text I have seen,
          >> "Craft
          >> of Functional Programming" by Thompson, and what is this chapter
          >> called: "Program Testing". So, there we go. Two feet in my mouth in
          >> less than 2 days.
          >
          > I believe Knuth said it best when he wrote "Beware of bugs in the
          > above code; I have only proved it correct, not tried it." Functional
          > programming allows for proofs. It doesn't mean that you didn't typo
          > anything.
          [snip]

          Not to mention those of us who now consider testing as a design
          practice which you need to do before you write code. Relevant no matter
          what language you're using.

          Adrian
        • Terrence Brannon
          ... Well, you can black-box test before you write code. But whitebox testing, which is based on knowing the internals of the code has to wait until the code is
          Message 4 of 13 , Apr 8, 2005
          • 0 Attachment
            Adrian Howard <adrianh@...> writes:


            > Not to mention those of us who now consider testing as a design
            > practice which you need to do before you write code. Relevant no matter
            > what language you're using.

            Well, you can black-box test before you write code. But whitebox
            testing, which is based on knowing the internals of the code has to
            wait until the code is written.


            --
            Carter's Compass: I know I'm on the right track when,
            by deleting something, I'm adding functionality.
          • Karl Scotland
            ... matter ... Really? How do you know what code to write? How do you know what its supposed to do? If you know that, you can write a test for it. By
            Message 5 of 13 , Apr 8, 2005
            • 0 Attachment
              --- In extremeperl@yahoogroups.com, Terrence Brannon <bauhaus@m...>
              wrote:
              > Adrian Howard <adrianh@q...> writes:
              >
              >
              > > Not to mention those of us who now consider testing as a design
              > > practice which you need to do before you write code. Relevant no
              matter
              > > what language you're using.
              >
              > Well, you can black-box test before you write code. But whitebox
              > testing, which is based on knowing the internals of the code has to
              > wait until the code is written.

              Really?

              How do you know what code to write? How do you know what its
              supposed to do? If you know that, you can write a test for it. By
              writing your tests, you are thinking about the interfaces, and
              responsibilties. Thus you are doing design.

              Karl
            • Adrian Howard
              ... Erm. No it doesn t. Why would you think it does? Adrian
              Message 6 of 13 , Apr 8, 2005
              • 0 Attachment
                On 8 Apr 2005, at 10:44, Terrence Brannon wrote:

                >
                > Adrian Howard <adrianh@...> writes:
                >
                >
                >> Not to mention those of us who now consider testing as a design
                >> practice which you need to do before you write code. Relevant no
                >> matter
                >> what language you're using.
                >
                > Well, you can black-box test before you write code. But whitebox
                > testing, which is based on knowing the internals of the code has to
                > wait until the code is written.

                Erm. No it doesn't. Why would you think it does?

                Adrian
              • Adrian Howard
                ... ... and there s also the issue over testing. Doing pointless black-box testing that could never break in any real world situation. Adrian
                Message 7 of 13 , Apr 8, 2005
                • 0 Attachment
                  On 8 Apr 2005, at 10:44, Terrence Brannon wrote:

                  >
                  > Adrian Howard <adrianh@...> writes:
                  >
                  >
                  >> Not to mention those of us who now consider testing as a design
                  >> practice which you need to do before you write code. Relevant no
                  >> matter
                  >> what language you're using.
                  >
                  > Well, you can black-box test before you write code. But whitebox
                  > testing, which is based on knowing the internals of the code has to
                  > wait until the code is written.

                  ... and there's also the issue over testing. Doing pointless black-box
                  testing that could never break in any real world situation.

                  Adrian
                • Terrence Brannon
                  ... whitebox testing means looking at your code and writing tests based on what you see there. until the code is written there is nothing that can be seen or
                  Message 8 of 13 , Apr 8, 2005
                  • 0 Attachment
                    Adrian Howard <adrianh@...> writes:

                    > On 8 Apr 2005, at 10:44, Terrence Brannon wrote:
                    >
                    >> Well, you can black-box test before you write code. But whitebox
                    >> testing, which is based on knowing the internals of the code has to
                    >> wait until the code is written.
                    >
                    > Erm. No it doesn't. Why would you think it does?

                    whitebox testing means looking at your code and writing tests based on
                    what you see there. until the code is written there is nothing that
                    can be seen or whitebox-tested.

                    --
                    Carter's Compass: I know I'm on the right track when,
                    by deleting something, I'm adding functionality.
                  • Curtis Poe
                    ... It s takes me about two seconds to say I m going to write this line of code. I had better write a test for it first. Cheers, Ovid [Non-text portions of
                    Message 9 of 13 , Apr 8, 2005
                    • 0 Attachment
                      On Apr 8, 2005, at 4:22 PM, Terrence Brannon wrote:
                      > whitebox testing means looking at your code and writing tests based on
                      > what you see there. until the code is written there is nothing that
                      > can be seen or whitebox-tested.

                      It's takes me about two seconds to say "I'm going to write this line of
                      code. I had better write a test for it first."

                      Cheers,
                      Ovid


                      [Non-text portions of this message have been removed]
                    • Rob Kinyon
                      ... According the XP methodology, whitebox testing is a smell that you didn t write enough tests at first. *wink* Rob
                      Message 10 of 13 , Apr 8, 2005
                      • 0 Attachment
                        > whitebox testing means looking at your code and writing tests based on
                        > what you see there. until the code is written there is nothing that
                        > can be seen or whitebox-tested.

                        According the XP methodology, whitebox testing is a smell that you
                        didn't write enough tests at first. *wink*

                        Rob
                      • Adrian Howard
                        ... True, but sometimes I have to write those tests to demonstrate to myself where I have fouled up :-) Adrian
                        Message 11 of 13 , Apr 10, 2005
                        • 0 Attachment
                          On 9 Apr 2005, at 01:18, Rob Kinyon wrote:

                          >
                          >> whitebox testing means looking at your code and writing tests based
                          >> on
                          >> what you see there. until the code is written there is nothing that
                          >> can be seen or whitebox-tested.
                          >
                          > According the XP methodology, whitebox testing is a smell that you
                          > didn't write enough tests at first. *wink*

                          True, but sometimes I have to write those tests to demonstrate to
                          myself where I have fouled up :-)

                          Adrian
                        • Adrian Howard
                          On 9 Apr 2005, at 00:22, Terrence Brannon wrote: [snip] ... [snip] I guess my definition of whitebox testing is a little different from that. I consider it
                          Message 12 of 13 , Apr 10, 2005
                          • 0 Attachment
                            On 9 Apr 2005, at 00:22, Terrence Brannon wrote:
                            [snip]
                            > whitebox testing means looking at your code and writing tests based on
                            > what you see there. until the code is written there is nothing that
                            > can be seen or whitebox-tested.
                            [snip]

                            I guess my definition of whitebox testing is a little different from
                            that. I consider it testing with knowledge of the internals - no matter
                            when you actually implement them.

                            If I write a test for an implementation specific private method I'll
                            call it a whitebox test even if I write the test before I write the
                            method (which is almost always what I'll do). I guess you'd only call
                            it a whitebox test if you wrote the test after you wrote the method -
                            even if it's exactly the same test ?

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