Sorry, an error occurred while loading the content.

Re: [extremeperl] Terrence the Hypocrite

Expand Messages
• ... 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
• ... 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.
• ... [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
• ... 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.
• ... 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
• ... 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
• ... ... 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
• ... 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.
• ... 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]
• ... 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
• ... 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
• 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.