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

Terrence the Hypocrite

Expand Messages
  • Terrence Brannon
    ... 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:
    Message 1 of 13 , Apr 3, 2005
    • 0 Attachment
      Hypocrisy One:
      -------------

      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"


      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.
    • 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 2 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 3 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 4 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 5 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 6 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 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.

                  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 8 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 9 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 10 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 11 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 12 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 13 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.