From: "Bayley, Alistair"
<alistair_bayley.at.ldn.invesco.com@...>
To: "'testdrivendevelopment@yahoogroups.com'"
<testdrivendevelopment.at.yahoogroups.com@...>
Sent: Friday, September 09, 2005 7:08 AM
Subject: RE: [TDD] Strong Typing vs Strong Testing (was: .NET Properties V
iolate YAGNI?)


>> From: Frank Mueller [mailto:frank@...]
>>
>> The examples are Smalltalk, Ruby and Python. My intend was to
>> show, that a compile-time
>> type checking needs the information about the types inside
>> the source code for this
>> checking. Chicking at runtime doesn't need this information here.
>
> Compile-time type checking does not *require* type annotations. Many
> languages (Java, C++, C#, etc) demand them, and this is a source of pain
> for
> some people. But you can have compile-time type checking without type
> annotations via type inference; Haskell, ML, Ocaml, and some Scheme
> systems
> have this.

This is about the fifth time you have made that assertion. As far
as I can tell, ***all*** type checking systems need help from
the program author at some time or other in all but the simplest
cases, and ***no*** compile time type checking system smoothly
and transparently covers what developers actually want to, and
need to, do in a program.

My personal opinion is that arguing over the merits of manifest
versus implied, compile time versus dynamic, strong versus
weak or any of the other distinctions between different styles
of type checking is a bit like arguing the distinctions between
protein heavy, carbohydrate heavy, fats and fibre diets when
the man is lying there starving to death.

Too many years ago I had a teacher who would ramble on
about the 1/4 inch drill story. He'd tell us that he had been
a purchaseing manager for a hardware chain, and how many
1/4 inch drills they had sold the previous year. Etc. And then
he'd say he had never met a customer who wanted 1/4 inch
drills. What they really wanted was 1/4 inch holes!

I've never seen a working developer who wanted a type
checking system. I've seen lots of developers who wanted
good support for writing programs with low levels of
defects.

The best type system in the world is not going to help if
you haven't started out by identifying the *distinct* domain
concepts that really have to stay distinct and encapsulated
them in a way that the type system can *then* check that
they're used in a sane way.

There's a very simple thing that Java and similar languages
that use manifest typing could do to help this along. It's
so simple that I predict you won't see it in any mainline
language in the next decade (although you might see it
as an option in a high-end IDE).

Provide a switch that causes a compile error if any of
the fundamental types or fundamental libraries are used
without the "private" scope.

It's that simple: the fundamental language types, and
the basic language libraries, do not, and let me repeat
that, do not represent any concepts that your application
actually needs. At best they represent bizzare
oversimplifications of those concepts that can't be told
apart by the type checking mechanism.

There's a concept in American law, and I presume
in many other legal systems, called the attractive
nuisance. A nuisance is, of course, something harmful,
and attractive has its usual meaning. The story I heard
to illustrate the point was a company that had a nice
concrete lined open vat of some form of acid that looked
like water. It was, of course, surrounded by a fence and
warning signs. That didn't stop several small boys who
wanted a swim on a hot day.

Arguing about whose type system is better without
looking at what those type systems actually do to
support real program correctness doesn't advance
the art of writing low defect programs one iota.

And that's my say on the matter.

John Roth







>
> Alistair
>
> -----------------------------------------
> *****************************************************************
> Confidentiality Note: The information contained in this message, and any
> attachments, may contain confidential and/or privileged material. It is
> intended solely for the person(s) or entity to which it is addressed.
> Any
> review, retransmission, dissemination, or taking of any action in
> reliance upon this information by persons or entities other than the
> intended recipient(s) is prohibited. If you received this in error,
> please
> contact the sender and delete the material from any computer.
> *****************************************************************
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>