Re: Is strong typing worth the cost?

[Darren New <dnew@san.rr.com>]

Wes Groleau wrote:
> OK, I take back the comment about your Ada knowledge.
> Still, only one of these declares a type.  Your terminology
> induced misunderstanding.

Fair enough. Actually, when I said "every type has to be declared
twice", I was thinking about subprogram declarations, so yes, my bad.

Limited types wind up being declared twice, in general, yes? Once in the
"public" part of the spec and once in either the private part or the
body? Subprogram names show up at least twice (at the start and end of
the subprogram) and usually in the package spec too. Etc.

> > Now, if I change X to be a date instead of an age, how many places to I
> > need to change it? I need to change it two places in Y's body and one
> 
> Sure.  But changing something from "Date" to "Age" in the middle
> of the project is a sure sign you didn't have a clue what
> you were working on when you started!  Changing from an integer
> to a disk-based database is even more extreme (pun intended).

Well, yes and no. One of the points of XP is that you *don't* know
everything you're going to put in the code before you start. Secondly,
again, XP is for where the specs change over the lifetime of the
development. If you're running (say) a payroll system, you can't
possibly predict what Congress is going to want to see on tax reports
three years from now. XP explicitly says don't even *look* at
requirements that are more than a week away from being implemented.

I picked date->age specifically because I used to write life insurance
proposal software, and that kind of change got to be so common that I
made up a special UI widget that would accept either a date or an age,
as an example. 

> When they are used in a place where it truly doesn't
> matter, a generic or a tagged type might be appropriate.

That only works if you know when you declare the type that it's going to
be used in ways where it doesn't matter. I.e., you have to plan ahead to
make it a generic or tagged type. And if you change it from non-generic
to generic, you now have to go find all the places you used the
non-generic type and instantiate the right thing, and etc. Again, a lot
more changes than you would need with a dynamically-typed system.

And then when you refactor and move some of the routines into a
different package, then you have to find every reference to it and
change the "with" clause and the "use" clause or the fully-qualified
calls.
 
> In either case, scripting a global change is quite easy.

Well, unless there's other people working on other stuff in the same
package, yes. :-?  No question that you can *work around* all the extra
work that Ada makes you do when you frob requirements twice a week. But
it's certainly more efficient to code in a language with less
redundancy, and XP advocates claim it's more efficient to get a working
result as well.

> > > Ada does not require a subprogram to be written to compile
> > > a call to it.  It does require it to be written (or a "stub"
> > > for it) to execute the call.
> >
> > It requires the subprogram to be declared to compile a call to it, and
> > it requires the subprogram to be implemented to link. (The difference
> 
> No, to link you only need a stub, if you are not debugging
> that subroutine.  If you are, the obviously it has to be written
> either way.

You've still implemented the stub. To run the test, you still have to
code the declaration of the subprogram and you still have to code the
body of the subprogram. The body doesn't have to be *right*, but it
still has to be coded.

> > between being able to compile and being able to link is kind of academic
> > when the goal is to do both at least five times an hour, so I wasn't
> 
> You make it sound like XP is a euphemism for rapid trial and error.

Yes, amongst other techniques. It's a whole raft of maybe a dozen
different techniques that basically make rapid trial and error work
better (so it's claimed) than thinking things out well in advance and
planning before coding. One of the rules is that every bit of knowledge
in the program is coded exactly once, which Ada doesn't do, as
demonstrated above. Another of the rules is that you never touch the
productive code unless there's a test that fails. I suppose you could
count "won't compile" as a failed test, but since XP uses Smalltalk and
the only reason for something not to compile is a very localized syntax
error, its hard to say whether an XPer would say "fails to compile"
counts as a failing test.
 
> Why not make a hundred copies of the program each cycle,
> make random changes, and keep the few that look promising?
> Genetic algorithm--sort of.

Well, you could, but it wouldn't be XP.
 
> Seriously, when I have to debug Ada I can (usually)
> EASILY compile and run five or ten times an hour.
> But I rarely need five or ten tries to make it work.

No, the point of 5 or 10 changes an hour is that you implement 5 or 10
requirements per hour. 
 
> And when it's old code, those irritating declarations
> help my changes to be based on understanding instead of
> guessing or random changes.

I'm not trying to say XP is superior to the normal mechanisms used by
Ada. I'm just saying that *if* you're doing XP, doing it with something
like Smalltalk is better than doing it with something like Ada, in part
because of the strictness of Ada's type system that requires extra work
to make things compile/link and extra redundancy that assures the
compiler you mean what you said.

In other words, saying that strict typing is always superior is wrong,
unless you want to throw away all the experience of successful XP-based
development as being irrelevant or bogus in some other way. I.e., there
*is* evidence that weak typing buys you something, namely, the ability
to be more agile in the face of rapidly-changing specifications.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.