The Artima Developer Community
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

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 370 replies on 25 pages [ « | 1 ... 14 15 16 17 18 19 20 21 22 ... 25  | » ]
Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Static Type Checks are not Tests Posted: Jul 24, 2007 4:47 AM
Reply to this message Reply
Advertisement
> Erik Engbrecht wrote
> > Yes, I think static analyzers should be leveraged far
> more
> > than they are. The problem is they are effectively
> just
> > warnings, and it is easy to simply ignore warnings.
>
> I think you just switched topic to project management -
> failed tests are also just warnings - software is
> shipped with known bugs. We bother about the
> unknown bugs because we can't assess the damage that they
> might do or whether they breach contractual agreements.

Not quite a management problem. Static analyzers tend to say "look here, there may be a problem," and that is their intent, rather than "look here, there is a problem."

Just to think out loud, I think static analyzers would be more useful if they could automatically generate a unit test that would exhibit the problem in the code.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Static Type Checks are not Tests Posted: Jul 24, 2007 9:48 AM
Reply to this message Reply
Erik Engbrecht wrote
> Not quite a management problem. Static analyzers tend to
> say "look here, there may be a problem," and that
> is their intent, rather than "look here, there is a
> problem."

"Dialyzer is completely automatic (in particular it does not require any annotations from the user), very easy to use, and currently supports various modes of operation. Its analysis is precise (no false alarms are reported) and typically quite fast..."

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 5:43 AM
Reply to this message Reply
> > The only changes that do not require testing are the
> very
> > trivial ones, which is a very limited set of changes.
>
> That's incorrect.
>
> Renaming a type can sometimes impact hundreds of different
> classes. It's something that's 100% safe in a statically
> typed language but requires heavy testing with a dynamic
> language, to the point that I sometimes decide not to do
> it because I think it's not worth the risk.
>
> IDEA and Eclipse offer more than thirty such refactorings,
> all of which are 100% safe, and this number is growing
> with each new release, so I would certainly not call this
> set "limited" nor "trivial".
>
> --
> Cedric
> http://testng.org

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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 6:05 AM
Reply to this message Reply
> > IDEA and Eclipse offer more than thirty such
> refactorings,
> > all of which are 100% safe, and this number is growing
> > with each new release, so I would certainly not call
> this
> > set "limited" nor "trivial".
>
> 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.

There is nothing to correct. That's what "100% safe" means.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 6:55 AM
Reply to this message Reply
> But it does not mean anything that the code passed
> compiling.

Yes, it does. It means your code is correct according to a certain set of rules and is free of certain common classes of errors.

> 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?

Because compilation takes far less time than running it.

> just run the
> program and correct it as you go. It's a much more
> rewarding experience.

I find locating typos very tedious. When I program in LISP, I compile everything. Of course, that doesn't stop me from doing interactive development, but it does give me warnings like "this symbol is not defined" or "this function does not exist."

So sometimes I say - of course that function doesn't exist, I'm not done writing it yet! Or I say - whoops, typo, I spelled that name wrong.

Finding such mistakes quickly is much more rewarding that waiting for them to cause odd behaviour in running code.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 9:43 AM
Reply to this message Reply
Achilleas Margaritis wrote
> But it does not mean anything that the code passed
> compiling.

Cedric was talking about automatic behaviour-preserving refactoring, if it was correct before the refactoring then it would still be correct after the refactoring - without type checking, without testing.


> 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.

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?

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 10:01 AM
Reply to this message Reply
> 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.

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).

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.

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

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 10:34 AM
Reply to this message Reply
Cedric Beust wrote
> Statically typed languages allow you to write less tests.

Do they? Can you demonstrate that is true?

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 10:56 AM
Reply to this message Reply
> Cedric Beust wrote
> > Statically typed languages allow you to write less
> tests.
>
> Do they? Can you demonstrate that is true?

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 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.

Hence my claim that you need more tests in dynamically typed languages than statically typed ones.

Is that close enough to a proof?

--
Cedric
http://testng.org

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 11:15 AM
Reply to this message Reply
Cedric Beust wrote
> > > Statically typed languages allow you to write less
> > tests.
> >
> > Do they? Can you demonstrate that is true?
>
> 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.
>
> Hence my claim that you need more tests in dynamically
> typed languages than statically typed ones.
>
> Is that close enough to a proof?

Not even remotely close ;-)

I don't think programmers using dynamically checked languages write tests "to catch type mistakes" at all.

They don't write tests to check internal coherence, they write tests to check external correspondence with expected behavior.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 11:23 AM
Reply to this message Reply
> Not even remotely close ;-)
>
> I don't think programmers using dynamically checked
> languages write tests "to catch type mistakes" at all.

That's a totally different topic and it doesn't change anything to my proof.

Let me phrase it another way.

A test T in a statically typed language can guarantee that the software is correct while the same program written in a different language can still pass test T and yet fail in other areas (that wouldn't fail in a statically compiled language).

What you are saying is that "dynamic programmers" are more lazy and are not writing tests to catch type errors. Well, they should (or use a statically typed language, which will do it for them).

--
Cedric
http://testng.org

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 12:00 PM
Reply to this message Reply
> What you are saying is that "dynamic programmers" are more
> lazy and are not writing tests to catch type errors.
> Well, they should (or use a statically typed language,
> , which will do it for them).

Type checking is like rinsing of your plate and tests are running it through a dish-washer.

Dynamic typing argument: Rinsing the plate is a waste of time because the dish-washer will still do the same amount of work.

Static typing argument: The dishwasher isn't completely effective and you need to rinse if you want the dishes to come out clean.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 2:51 PM
Reply to this message Reply
Cedric Beust wrote

> A test T in a statically typed language can guarantee that
> the software is correct while the same program written in
> a different language can still pass test T and yet fail in
> other areas (that wouldn't fail in a statically compiled
> language).

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.

The statically checked program passes T and so is correct.

The dynamically checked program passes T and so is correct.

Anything else is undefined behavior.

So how do "Statically typed languages allow you to write less tests"?


> What you are saying is that "dynamic programmers" are more
> lazy and are not writing tests to catch type errors.
> Well, they should (or use a statically typed language,
> , which will do it for them).

I'm saying you're making an incoherent argument.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing Posted: Jul 26, 2007 8:27 PM
Reply to this message Reply
> 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. The purpose of a specification is so that a broader audience can understand it. If your tests are code, or some psuedo-code-like-DSL-thing, then only programmers can understand it. Furthermore, specs are supposed to be fairly complete and higher level, while unit tests by their nature focus on individual elements.

All unit tests do is confirm that a piece of your code is working the way you think it should work. Now, that is an extremely important function. I'm not in the least downplaying the importance of unit tests. But to assert that it's a specification is rather crazy.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 27, 2007 9:13 AM
Reply to this message Reply
Erik Engbrecht wrote
> 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. The purpose of a
> specification is so that a broader audience can understand
> it. ... But to assert that it's a specification is rather crazy.

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".

Flat View: This topic has 370 replies on 25 pages [ « | 14  15  16  17  18  19  20  21  22 | » ]
Topic: Programming with "Duh" Typing Previous Topic   Next Topic Topic: Python 3000 Plea for Help

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use