Weblogs Forum - Programming with "Duh" Typing

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Programming with "Duh" Typing

370 replies on 25 pages. Most recent reply: Aug 8, 2007 9:54 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 370 replies on 25 pages [ « | 1 ... 22 23 24 25 ]

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Verification and Validation

Posted: Aug 3, 2007 10:43 AM

James Watson wrote

> > Which is less interesting than it might seem, IEEE 729
> > gave three definitions for verification :-)
> >
> > - determining whether or not the products of a given
> phase
> > fulfil the requirements established during the previous
> > phase
>
> Testing doesn't do this.

Yes it does.

> > - formal proof of program correctness
>
> Testing doesn't do this.

True by definition.

> > - establishing whether or not stuff conforms to
> specified
> > requirements
>
> Testing doesn't do this.

Yes it does.

> > And one definition for validation:
> >
> > - evaluating software at the end of development to
> ensure
> > compliance with software requirements
>
> Testing doesn't do this.

Partially it does, but not fully.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: word games

Posted: Aug 3, 2007 10:58 AM

> > > When we use tests to check the program conforms to
> > > spec, and the program passes all tests, and we're
> using
> > > an ordinary definition of program correctness, then
> the
> > > program is obviously 'correct'.
> >
> > If all tests pass, it doesn't mean that the spec is
> > completely satisfied unless the spec is defined by the
> > tests.
>
> It isn't true unless it's true! What a tortuous way to
> avoiding saying - if the spec is defined by tests and all
> the tests pass then the spec is completely satisfied.
>

So we have a fundamental disgree on whether tests are a sufficient for of specification. I believe they are neither a form a specification nor a potential substitute for specification.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: word games

Posted: Aug 3, 2007 11:15 AM

Erik Engbrecht wrote
> So we have a fundamental disgree on whether tests are a
> sufficient for of specification.

No. We've been here before [Jul 27, 2007 9:13 AM]

> I believe they are neither a form a specification nor a
> potential substitute for specification.

And I'll leave you to argue that out with the Agile crowd ;-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: word games

Posted: Aug 3, 2007 11:25 AM

> James Watson wrote
> > I you define correctness as passing all tests, creating
> a
> > new test that exposed an existing issue (with regard to
> > specifications) would make the code incorrect.
>
> And why would we create a new test?

Why wouldn't we? Is there an argument here?

>
> > > How are implementations normally checked against
> > > specs? ...
> >
> > Testing.
>
> So normally tests represent the specification?
>
>
> > How is this incompatible with what I am arguing?
>
> The only way we can validate a program 'meets all
> requirements' is to ask someone "is this what you
> wanted?".

No, it's not.

> We can verify that a program is 'correct' by demonstrating
> that it satisfies the spec.

The spec is derived from the requirements. It's documentation of the requirements. Validating against the spec is validating against requirements as long as the specifications accurately represent the requirements. This is the point of documenting the requirements in the specification and getting people to agree that they represent the requirements. Once this is completed, the specifications are considered to be the requirements.

> > > When we use tests to check the program conforms to
> > > spec, and the program passes all tests, and we're
> using
> > > an ordinary definition of program correctness, then
> the
> > > program is obviously 'correct'.
> >
> > If all tests pass, it doesn't mean that the spec is
> > completely satisfied unless the spec is defined by the
> > tests.
>
> It isn't true unless it's true! What a tortuous way to
> avoiding saying - if the spec is defined by tests and all
> the tests pass then the spec is completely satisfied.

I'm not avoiding saying that. It's a tautology. There's no need to point it out. If the floor is 'what I stand on' then 'what I stand on' is the floor. You can prove any statement if you can choose your axioms. Logic is only relevant to the 'real' world if we choose axioms that match our experience.

Almost no real specifications are documented in this way and most applications requirements that can be specified in other manners cannot be specified with tests. When did everyone in this thread agree that we were only talking about this minuscule subset of specifications?

> You can never mathematically prove a program to be correct
> when your idea of 'correct' is 'meets all requirements' -
> it's a category error - 'meets all requirements' is
> outside the formal domain of mathematics.

Nonsense. Specifications are the formal statement of requirements. From a development perspective, the specifications are the requirements.

Let's say hypothetically that I agree that "meets all requirements" is not the proper way to state what I meant and I should have said "valid with respect to it specifications". It really makes no difference because for all intents and purposes, these are basically equivalent statements. But let's say I agree that I was wrong to state it that way. What would that prove exactly?

I'll even agree to use the term specification from now on at least in the context of this thread. Will that satisfy you?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Verification and Validation

Posted: Aug 3, 2007 11:34 AM

> James Watson wrote
>
> > > Which is less interesting than it might seem, IEEE
> 729
> > > gave three definitions for verification :-)
> > >
> > > - determining whether or not the products of a given
> > phase
> > > fulfil the requirements established during the
> previous
> > > phase
> >
> > Testing doesn't do this.
>
> Yes it does.

Perhaps you are quarreling about a definition without providing it.

How do you define 'determining' (really 'determine')? I assume you are not attaching a meaning that includes absolute certainty?

> > > - establishing whether or not stuff conforms to
> > specified
> > > requirements
> >
> > Testing doesn't do this.
>
> Yes it does.

Again I would need to understand how you define 'conforms'.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: word games

Posted: Aug 4, 2007 4:41 PM

James Watson wrote
> > > I you define correctness as passing all tests,
> > > creating a new test that exposed an existing issue
> > > (with regard to specifications) would make the code
> > > incorrect.
> >
> > And why would we create a new test?
>
> Why wouldn't we? Is there an argument here?

I don't suppose we're creating new tests just for the fun of it, so there must be some other motive, such as - the existing tests don't adequately represent the spec, the spec changed...

> > The only way we can validate a program 'meets all
> > requirements' is to ask someone "is this what you
> > wanted?".
>
> No, it's not.

Yes it is.

> > We can verify that a program is 'correct' by
> demonstrating
> > that it satisfies the spec.
>
> The spec is derived from the requirements. It's
> documentation of the requirements. Validating against the
> spec is validating against requirements as long as the
> specifications accurately represent the requirements.
> This is the point of documenting the requirements in the
> e specification and getting people to agree that they
> represent the requirements. Once this is completed, the
> specifications are considered to be the requirements.

Yes, the spec is derived from requirements.

No, the spec is not considered to be the requirements - see exception clause "as long as the specifications accurately represent the requirements".

-snip-
> Almost no real specifications are documented in this way
> and most applications requirements that can be specified
> in other manners cannot be specified with tests.

Your omniscience with respect to how real specifications are documented leaves nothing for me to say.

> > You can never mathematically prove a program to be
> correct
> > when your idea of 'correct' is 'meets all requirements'
> -
> > it's a category error - 'meets all requirements' is
> > outside the formal domain of mathematics.
>
> Nonsense. Specifications are the formal statement of
> requirements. From a development perspective, the
> specifications are the requirements.

Sense. From a development perspective, specs are a formalization of the requirements - thinking they are the requirements is a sign of confusion.

> Let's say hypothetically that I agree that "meets all
> requirements" is not the proper way to state what I meant
> and I should have said "valid with respect to it
> specifications". It really makes no difference because
> for all intents and purposes, these are basically
> equivalent statements. But let's say I agree that I was
> wrong to state it that way. What would that prove
> exactly?

If you're talking about conforms to spec and Achilleas Margaritis is talking about conforms to spec, then we should wonder what he meant when he wrote "I would like to point out that proving statically that software is correct is impossible." [Jul 30, 2007 6:51 AM]

Maybe he was talking about the halting problem?

Maybe he meant impractical rather than impossible?

Maybe (given that he followed with "A static type system only proves that what you typed makes some kind of sense") he was only talking about what the "static type systems of C/C++/Java/C#" [Aug 2, 2007 10:17 AM] can do, not what other tools can do?

If Achilleas wasn't invoking the halting problem, and wasn't restricting his comments to compiler type systems, and really meant impossible rather than impractical - is he right?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: word games

Posted: Aug 6, 2007 6:31 AM

> -snip-
> > Almost no real specifications are documented in this
> way
> > and most applications requirements that can be
> specified
> > in other manners cannot be specified with tests.
>
> Your omniscience with respect to how real specifications
> are documented leaves nothing for me to say.

This kind of response makes trying to discuss things with you a waste of time. This is a crucial point and you don't make any argument against it. Instead, you dismiss it with snide and insulting comment. If you don't think I know anything, then why bother having a discussion with me? In any event, I've decided this discussion is not (and has not been) worth bothering over.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: word games

Posted: Aug 7, 2007 11:25 AM

> > -snip-
> > > Almost no real specifications are documented in this
> > way
> > > and most applications requirements that can be
> > specified
> > > in other manners cannot be specified with tests.
> >
> > Your omniscience with respect to how real
> specifications
> > are documented leaves nothing for me to say.
>
> This kind of response makes trying to discuss things with
> you a waste of time. This is a crucial point and you
> don't make any argument against it. Instead, you dismiss
> it with snide and insulting comment. If you don't think I
> know anything, then why bother having a discussion with
> me? In any event, I've decided this discussion is not
> (and has not been) worth bothering over.

Your claim requires knowledge of how all real specifications are documented - omniscience - I don't think you know that.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: word games

Posted: Aug 7, 2007 12:45 PM

> Your claim requires knowledge of how all real
> specifications are documented - omniscience

Firstly, that's not omniscience. Secondly knowing that most specifications are not documented as tests doesn't require knowing how all real specifications are documented. Thirdly, even if I don't really know it, it doesn't make it an incorrect statement. Lastly, even if is not true, at least some specifications (all the ones I have ever seen) are not documented as tests and that's all that really matters.

Assuming that we are only talking about specifications documented as tests is convenient to you. That much is obvious. But convenient assumptions are not interesting to me and at this point this discussion has lost momentum and I'm tired of bickering with you.

> - I don't think you know that.

Arguing about I know or don't know is pointless.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: word games

Posted: Aug 8, 2007 9:17 AM

James Watson wrote
> Firstly, that's not omniscience.

Just for fun let's add the missing context - "Your omniscience with respect to how real specifications are documented..."

> Secondly knowing that most specifications are not
> documented as tests doesn't require knowing how all real
> specifications are documented.

Are you going to make a data-based statistical argument?

> Thirdly, even if I don't really know it, it
> doesn't make it an incorrect statement.

If you don't really know it, why state it as a categorically true "crucial point" of your argument - doing so just undermines how much we trust what you say.

> Lastly, even if
> is not true, at least some specifications (all the ones I
> have ever seen) are not documented as tests and that's all
> that really matters.

And how are implementations normally checked against specs?

> Assuming that we are only talking about specifications
> documented as tests is convenient to you. That much is
> obvious. But convenient assumptions are not interesting
> to me and at this point this discussion has lost momentum
> and I'm tired of bickering with you.
>
> > - I don't think you know that.
>
> Arguing about I know or don't know is pointless.

What you described as "a crucial point" seems to have been plucked from thin air.

It is difficult to have a sensible discussion when you just make stuff up to suit the argument you wish to make.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: word games

Posted: Aug 8, 2007 9:54 AM

I've determined that there is nothing to gained through discussions with you. You clearly are more interesting in 'winning' than exchanging ideas. Feel free to get your last word in. I will not be responding.

Flat View: This topic has 370 replies on 25 pages [ « | 22 23 24 25 ]

Previous Topic

Next Topic