Hi,

"Thaddeus L. Olczyk" wrote:

> Frankly, I don't buy what a lot of the studies say.... The point is that
> studies are unreliable in SE.

Maybe you were exaggerating for effect, but one expects that at least a few
semi-competent people would be able to find at least some seriously compelling
evidence in favor of strong typing. I'm not opposed to constant types, I just
don't think the pros and cons for it are quite so clear cut in "average"
(versus "special") cases, _all_ things considered.

> My only serious experience with dynamic typing is

Argument by anecdote.... :-)

> >> So why not do this? Make Ruby a
> >> language with both static and dynamic type.
> >
> >I think this might be possible, but I think there would be all sorts of
> >complex issues concerning the often subtle and indirect interactions of
> >these 2 very different styles of doing stuff.
> >
> I don't think so. You need a casting mechanism ( and a null object
> for when you can't cast ) between the two. You have method parameters
> which are either typed or untyped. If you call a method with a an
> untyped object and that method  requires a type, you do a typecast
> before you pass it. If you call a method requiring an untyped object
> with a typed object, the compiler simply ignores the type information.

"simply ignores the type information"? Well, I'd be surprised if that didn't
lead to many violations of the principle of least surprise in practice,
especially when you start mixing up lots of library modules and such written
by many people. (I wouldn't mind being surprised in this case, however.)

> The hard part is deciding what classes can and coannot be used by
> static types. Even that is not hard.

We'll see.... If things were as easy as people expect with respect to language
design, I think that the current state of the art wouldn't be so primitive
relative to the number of years that people have been inventing such things.

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)