Re: dynamic type checking - a pauline conversion?

From: Dave Harris (brangdon_at_cix.co.uk)
Date: 04/03/04 

Date: Sat, 3 Apr 2004 17:48 +0100 (BST)

tmh@possibility.com (thoff) wrote (abridged):
> Dave Harris wrote:
> > The idea of shipping untested code, such that the end-user is the
> > first person to see it executing, fills some of us with horror. So we
> > need to test, preferably in rigorous, systematic form. So TDD is
> > effectively already paid for.
>
> Products have system tests and acceptance tests. These are run before
> a customer ever gets the product so you should be filled with joy.

[This reply is delayed because I've been off skiing for a couple of
weeks.]

Yes indeed. Higher level tests are necessary - but not sufficient. The
problem is one of coverage. If you have multiple units, each with multiple
code paths, it's hard to get good coverage by only testing at the system
level. By testing each unit in isolation it's much easier to give it a
full workout. You don't have to think, "What input can I give A which will
make it produce outputs which when fed to B will force B through all its
code paths." And so on for however many levels the system has.

> If you shipped a product that only had been unit tested i would
> be equally filled with horror.

Agreed. No-one is proposing that.

> I could make a credible argument that careful coding
> produces few bugs so development will go faster without
> unit testing.

Unit testing isn't incompatible with careful coding. If you are saying, "I
never produce bugs so I don't need to test for them", then (a) I have
trouble believing you, and (b) the same argument applies to
static/manifest type checks. If you are saying that manifest/static types
encourage careful coding, then so does TDD.

> If there is an acceptance test then the
> customer won't see any bugs that they care about so the
> quality from the customer point-of-view is always preserved.

I disagree - customer acceptance tests are rarely comprehensive for the
reason I gave above. (And because it is not really the customers job to
find programmer mistakes. They will be thinking at a whole other level of
abstraction.)

> > There are differences. Eg because a static type system is supposed to
> > be statically decidable. Compile-time stuff is simply not as powerful
> > and flexible as run-time stuff.
>
> True. You have to decide if the cost of that power is acceptable
> for your context. For me that is a tradeoff curve. For others,
> like religion or politics, it is a point.

For me it is a tradeoff. I think it will vary with the kind of project. To
get the highest quality, with time and money no object, we should use all
3 techniques: unit tests, DBC and static/manifest type checks. The
interesting question is, if you don't have unlimited time and money, which
should be dropped first. (If any: there's an argument that all would
actually pay for themselves, even in combination. I don't know if that is
true.)

> > Rigid, redundant code remains rigid redundant code even if some IDE
> > generates it for you.
>
> I don't agree the code is redundant or rigid.

You don't agree that manifest types add redundancy? That they make the
code harder to change? OK, that's a basic point of difference. I agree
that if static type checks were free we should use them. The argument for
static checking in a language like Haskell, which has type inference, is
much stronger than in "mainstream" languages like C++, Java, Eiffel etc.

I don't know of any XP projects which have used Haskell (or OCaml or
similar) - which is a shame. I think it would blow much of this debate
away. Indeed, I believe I said elsewhere that RCM's prediction may be
wrong, and what we might actually see as a result of TDD is not a shift to
dynamic languages but more emphasis on cheaper static ones.

(Which might be updated versions of current languages. Eg there are
movements in C++ community to add some type inference features.)

> Even if i did, if i can work with code in such way that it isn't,
> ie through an IDE, then it is effectively neither.

I don't believe the IDE can do that. Or rather, if it can, then so can the
compiler, and the IDE stops being a factor.

> It's interesting smalltalkers have always touted the productivity
> wins of their IDE. Now that the shoe is on the other foot it is no
> longer an acceptable arguement.

I didn't say the general argument was unacceptable. I disagreed with the
point of fact, ie that a good IDE can fully compensate for a poor
language. It can only do that if we never actually look at the underlying
manifestly typed code, and instead work with a latently typed IDE - but
then we are not really using the language we said we were.

-- Dave Harris, Nottingham, UK

Relevant Pages

  • Re: Is linq the final straw for VB?
    ... C++ and all other mathmetatical syntax ... RAD language VB is the better choice. ... is simply a lot more typing in VB. ... The VB.NET IDE ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Still clinking to Java?
    ... I was toying with saving effort by making the C version a DLL and redoing the GUI in my portable Cello GUI. ... But there would be new work on the engine, and just trying to get a clean compile of the C version under VC++ I saw enough to remind me I would rather work in Lisp. ... IDE investments can simply be skipped. ... I just don't want to switch language _at that point_ and recode ...
    (comp.lang.lisp)
  • Re: Why Ruby does not nead an ide
    ... Then look at the Smalltalk IDE. ... ground up to support the language - editing, browsing, debugging, ... It's the way most Forth programmers code, ...
    (comp.lang.ruby)
  • Re: Moving to C#
    ... > are still some concepts that neither language do particularly well. ... language parts inside Delphi). ... > What matters more to me is the quality and functionality of the IDE. ... C#Builder then I doubt it will actually play any role for C# developers. ...
    (borland.public.delphi.non-technical)