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

Re: [extremeperl] Terrence the Hypocrite

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

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