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 ... 15 16 17 18 19 20 21 22 23 ... 25 | » ]

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 11:11 AM

> > When we say "correct" I think we're saying that the
> > program corresponds to the spec as defined by our tests
> -
> > in this case "correct" is defined by our single test T.
>
> This is off-topic, but I find the idea of consider unit
> tests to be a specification to be one of the most
> ridiculus propositions I've ever heard.

Users of the popular next generation BDD frameworks like rSpec probably disagree.
http://rspec.rubyforge.org/

While I haven't used rSpec (but will on my next project) I like the whole idea thinking of tests as specifications.
Because tests describe if the software is correct based on possible scenario's.
If you have a spec that isn't tested you can't be sure the software is correct for that spec.
If you have untested code you cannot be sure it's doing what's specified.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 12:05 PM

> > > When we say "correct" I think we're saying that the
> > > program corresponds to the spec as defined by our
> tests
> > -
> > > in this case "correct" is defined by our single test
> T.
> >
> > This is off-topic, but I find the idea of consider unit
> > tests to be a specification to be one of the most
> > ridiculus propositions I've ever heard.
>
> Users of the popular next generation BDD frameworks like
> rSpec probably disagree.
> http://rspec.rubyforge.org/

Looking over the project has left me all the more convinced of what I said.

> While I haven't used rSpec (but will on my next project) I
> like the whole idea thinking of tests as specifications.
> Because tests describe if the software is correct based on
> possible scenario's.
> If you have a spec that isn't tested you can't be sure the
> software is correct for that spec.
> If you have untested code you cannot be sure it's doing
> what's specified.

Absolutely. Rspec looks interesting. It, and others like it, may be very useful tools. But they in no way replace specifications, at least not specifications that are worthwhile to generate.

But this is probably one of those semantic arguments again.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 12:06 PM

> The purpose of the system specification is twofold
> - "be sufficient basis for design and implementation..."
> - "be sufficient basis for preparation of Acceptance Test
> that the client can agree to as a determining test of the
> system supplied..."
>
> I think you've read too much into "corresponds to the spec
> as defined by our tests".

Probably. I hope I didn't start a flamewar.

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 12:10 PM

> > Cedric Beust wrote
>
> In a dynamically typed language, you have to write tests
> to catch type mistakes (such as the one described by James
> earlier, where he forgot a * in front of a variable,
> thereby declaring it as a literal instead of an array).
> These tests are unnecessary in statically typed languages
> s since they are caught by the compiler.
>
> On the other hand, I can't think of a test written in a
> statically typed language that would be made unnecessary
> in a dynamically typed language because of the fact that
> types are optional in that language.

I can.

Try the following in Java:

assertEquals("10000000000", (new Double(Math.pow(10, 10)).intValue()));

Ruby gives the expected result even for very large numbers:

10.power!100000

There are other problems.
If Java were truly static you wouldn't need to cast.
The following compiles in Java but throws a RuntimeException:

List a = new ArrayList();
a.add(new SomeObject());
for ( Iterator iter = a.iterator(); iter.hasNext(); ){
    AnotherObject value = (AnotherObject )iter.next();
}

And generics won't help all time. The following compiles but generates a ClassCastException:

List artists = new ArrayList();
artists.add(new Artist());
List<Album> albums = new ArrayList(artists);
for (Album album : albums) {
    album.getGenre();
}

In Java you can do:

"" + new Object()

Which might not give the expected result.
In Ruby this creates an error.

p "Object " + Object.new
=> TypeError: can't convert Object into String

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 12:43 PM

> Absolutely. Rspec looks interesting. It, and others like
> it, may be very useful tools. But they in no way replace
> specifications, at least not specifications that are
> worthwhile to generate.
>
> But this is probably one of those semantic arguments again.

Could you give an example of a specification that would be hard to replace with a test?

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 1:32 PM

> Could you give an example of a specification that would be
> hard to replace with a test?

Anything the customer is expected to understand:
- Concept of Operations
- Requirements / Use Cases
- Conceptual Design / Architecture
- Acceptance Test

Anything the whole technical team should understand (not just programmers):
- Architecture
- Detailed Design
- Algorithms

Anything outside the code:
- Database Design
- User Interface Design

Those are just examples. Do you need every one on every project? Absolutely not. In my opinion you almost always need a ConOps, the rest are "as needed" depending on size, content, and complexity.

Most of these specifications live well above the "unit test" level of granularity. IMHO specifications are for communicating what the forest looks like, not counting rings in individual trees. Unit tests are for counting rings.

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 3:58 PM

> > Could you give an example of a specification that would
> be
> > hard to replace with a test?
>
> Anything the customer is expected to understand:
> - Concept of Operations
> - Requirements / Use Cases
> - Conceptual Design / Architecture
> - Acceptance Test

You can automate acceptance tests and use cases:
http://fit.c2.com/
http://www.openqa.org/selenium/

>
> Anything the whole technical team should understand (not
> just programmers):
> - Architecture
I write tests for configurations. I also have Capistrano scripts that install a complete server with the necessary software. These scripts have tests.

> - Detailed Design
> - Algorithms

I don't think you want specifications of the algorithms to be different from how they are specified in your unit tests.
Sure you might want to change the wording and use something like the Fit.

> Anything outside the code:
> - Database Design

If you want the most up-to-date specs of the database design it should be the database that runs against the working tests.

> - User Interface Design

You can do a lot with view tests for web applications (with something like selenium).

> Most of these specifications live well above the "unit
> test" level of granularity. IMHO specifications are for
> communicating what the forest looks like, not counting
> rings in individual trees. Unit tests are for counting
> rings.

Sure you also need functional and integration tests to make sure your software follows specifications.
If you want to verify your software follows specifications, the specifications should be testable somehow.

Rusty Wright

Posts: 8
Nickname: lumpynose
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 27, 2007 11:48 PM

> But it does not mean anything that the code passed
> compiling. You have to run it afterwards, haven't you? and
> that's my point: since you are going to run it, why bother
> with static typing and even compilation? just run the
> program and correct it as you go. It's a much more
> rewarding experience.

Here's to hoping that you never have the job of writing the software that runs an autopilot for an airplane. Or a pacemaker.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 28, 2007 11:25 AM

Petrik,
I think you're entirely missing the point of what I'm saying. Specs generally should be:
(1) At a higher level than the code, usually significantly higher
(2) Understandable to people other than programmers, often non-technical people

From Selenium's page:
"Selenium is a test tool for web applications. Selenium tests run directly in a browser, just as real users do. And they run in Internet Explorer, Mozilla and Firefox on Windows, Linux, and Macintosh. No other test tool covers such a wide array of platforms.

* Browser compatibility testing. Test your application to see if it works correctly on different browsers and operating systems. The same script can run on any Selenium platform.
* System functional testing. Create regression tests to verify application functionality and user acceptance."

This is great stuff, but this has absolutely nothing to do with the type of material that should be in specifications. This is verifying the details. This is not communicating common understanding.

As for FIT, I fail to see how it could be scaled to any non-trivial application without making the test specifications completely incomphrehensible and divorced from the requirements.

Rusty Wright

Posts: 8
Nickname: lumpynose
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 28, 2007 11:22 PM


List a = new ArrayList();
a.add(new SomeObject());
for (Iterator iter = a.iterator(); iter.hasNext();) {
    AnotherObject value = (AnotherObject) iter.next();
}

"" + new Object()

In the first example you get the usual warning:


warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List
        a.add(new SomeObject());
             ^

In the second example, it doesn't compile:


not a statement
        "" + new Object();
           ^

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 29, 2007 12:22 PM

> In the first example you get the usual warning:
>


> warning: [unchecked] unchecked call to add(E) as a member
> of the raw type java.util.List
>         a.add(new SomeObject());
>              ^
>

But I can still get it to compile.

> In the second example, it doesn't compile:
>


> not a statement
>         "" + new Object();
>            ^
>

System.out.println("" + new Object());

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 6:33 AM

> > On the other hand, I can't think of a test written in a
> > statically typed language that would be made
> unnecessary
> > in a dynamically typed language because of the fact
> that
> > types are optional in that language.
>
> I can.
>
> Try the following in Java:
>

assertEquals("10000000000", (new Double(Math.pow(10,
> 10)).intValue()));

> Ruby gives the expected result even for very large
> numbers:
>

10.power!100000

This example has nothing to do with static typing. It has to do with the nature of the way the numbers are being represented. In Java you could use a BigInteger and it would work properly. A 32 bit integer type in a dynamic language would also be unable to store such large numbers.

> In Java you can do:
>

"" + new Object()

> Which might not give the expected result.
> In Ruby this creates an error.
>

p "Object " + Object.new
> => TypeError: can't convert Object into String

I think it's pretty odd to the one example of operator overloading in Java when Ruby supports operator overloading universally. And, of course, this has nothing to do with static typing. It has to do with operator overloading. It's actually a really nice feature and it annoys me when I can't use it in Python and have blot the code with str() calls.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 6:39 AM

> > In the first example you get the usual warning:
> >


> > warning: [unchecked] unchecked call to add(E) as a
> member
> > of the raw type java.util.List
> >         a.add(new SomeObject());
> >              ^
> >

>
> But I can still get it to compile.

The static typing system is still finding the problem. This is an example of a trade-off that sun engineers made for reasons that have nothing to do with this conversation. It's not relevant to the question of whether static typing is useful. This thread isn't even about Java.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 6:40 AM

>
> Is that a practical approach across all of software
> development or only in particular situations?
>
> Wouldn't it depend on the risks / losses (including user
> opportunity cost) of something going wrong?
>
> When might it be practical, when might it not?
>
> Would your opinion be different if you the programmer were
> liable for user losses?

Is there such a case out there? most programs contain an EULA which relieves the developer from any responsibility.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 6:49 AM

> > But it does not mean anything that the code passed
> > compiling. You have to run it afterwards, haven't you?
> and
> > that's my point: since you are going to run it, why
> bother
> > with static typing and even compilation? just run the
> > program and correct it as you go. It's a much more
> > rewarding experience.
>
> Achilleas, I mean no offense, but at this point, it just
> seems like there is an uncrossable gap between you and
> people who are trying to show you the benefits of
> statically typed languages. I'm seriously running out of
> ways to phrase my arguments, but I'll try one more:
>
> Statically typed languages allow you to write less tests.

My opinion is different: they don't help you write less tests. The number of tests to be written is independent of the type system, it depends on the requirements.

>
> Surely, that's something that you can see value in?
>
> When you rename a function in a dynamically typed
> language, you'd better hope that all your existing tests
> exercise all the possible code paths that might invoke
> that function, or you just broke your code in ways that
> might not be apparent for months (or even after shipping).

Unless you do functional testing which covers 100% all the requirements.

>
>
> Not only is writing these tests extra work for you, it's
> also error prone since it requires human intervention:
> you need to understand the code you are refactoring.

You also need to understand the code in statically typed languages as well, especially when the types at hand are interfaces.

>
> Renaming a method in a statically typed language requires
> zero tests. Once the refactoring is over, you know for
> sure that your code is just as correct as it was before,
> and that's a certainty you can never have with a
> dynamically typed language.
>
> As much as I enjoy writing tests for my code and thereby
> guaranteeing that my program is working as intended, the
> less tests I write, the more time I have to write code
> that might benefit my users more directly (or play World
> of Warcraft).
>
> --
> Cedric
> http://testng.org

Well, I want to agree with you, but reality proves otherwise. Time and again, the bugs I have in my programs are not caught by the compiler, even though I use C++ and Java.

Only yesterday I had a serious error which was in a test version sent to the customer, just because I was bored to run the whole series of tests.

The error was that the number of possible values of a field of a message was changed. This number was used as an index into a table. When the relevant message was received, the table had less entries than the value, and the C++ application died a painful death.

The offending table was used in a secondary case that I had forgotten it ever existed. I changed all code of the main cases, tested it all, shipped a test version to the customer, only to get a complain that "it crashes".

The static type system did nothing to prevent this.

A fully dependent type system would have caught this error at compile time.

Unless static type systems become fully dependent, they are not very practical.

So I prefer dynamic systems with interactive development, which cuts the development time at least by half, instead of the endless cycle of edit-compile-run-debug.

Flat View: This topic has 370 replies on 25 pages [ « | 15 16 17 18 19 20 21 22 23 | » ]

Previous Topic

Next Topic