From: Caleb Clausen <vikkous@...>
Date: 2005-06-01T02:42:49+09:00
Subject: Re: Intellisense and the psychology of typing

Austin Ziegler wrote:
>   # :parameter bar: aString
>   # :parameter baz: anArray or +nil+
>   # :returns: true if aString ...
> def foo(bar, baz = nil)

> I *WANT* type hints. I have believed
> that they are useful for things like SOAP from the beginning. I
> don't, however, want anything that looks like type declarations in
> the method declaration.

> Thus, if we allow people to do:
>
>  def foo(bar: String, baz: [ NilClass, Array ] = nil)
>   :
>  end
>
> They will. And all of the clean, easy-to-read-and-use Ruby code that
> we've come to love will go away.


I don't see how what you propose is all that different, semantically,
from calling out the type in the method header. You seem to be arguing
that: 'I want X like in other languages, but I don't want it to look
like it looks in other languages, because programmers from other
languages can import their bad habits.'  And to add a feature that
doesn't at least resemble the syntax for that feature in most other
languages is to compromise the (currently much battered) principle of
least surprise, at least for those programmers coming to ruby from
another language. The usual syntax where the type is embedded in the
variable definition has some advantages: it's compact, and it keeps
related things together. It's not for no reason that langauge after
language that actually implements this has done it (more-or-less) the
same way.

> Especially the -use part, because
> if I want to use a StringIO object now, I'll either need to modify
> the library, or get the String out of the StringIO before I can use it.

Specifying an overly restrictive type is an error. One can write a bad
program in any language, as the various obfuscated programming
contests have shown. Just because this is possible is no reason to
limit what good programs can do.

> It has been conclusively shown that type restrictions based on class
> names precisely do NOT do that in Ruby. Those restrictions, in fact,
> do NOT make the code more robust, and are therefore bad things.

Type and class are not the same thing. Class is one variety of type,
but there are others. For instance, there is the 'method signature',
(or duck type,) the set of methods that can be called. You try to
rebut this notion:

> I am absolutely positive that this should not be Ruby 2.0. It
> complicates things unnecessarily. I think that we can agree that
> Java-style Interfaces are poor substitutes for mixins; the proposal
> for interfaces in Ruby are equally poor.

You manage to criticize without letting us know what your actual
objections are. What things are complicated, and how? Java interfaces
are a poor substitute for mixins, but that's because they're not meant
to be mixins. I would say instead: Java interfaces are a poor
substitute for duck types, (since, like everything else in Java, they
require a big pile of declarations ahead of time) but we can make the
Ruby version work the right way, with a lot less declarations. (Only a
little pile.)

> Mmm. I'm not sure that I agree. Part of what I'm thinking here has
> to do with what Microsoft has done with the .NET platform and Java
> has done with Hotspot compiling. 

People expect too much from hotspot and the like. It works great for
Java, sure, but that's in large part because Java is statically typed.
Expecting the same performance in a language with no type information
on variables whatsoever is unrealistic.

And no, type inferencing _by_itself_ will not solve the problem. Type
inferencing works in ML, but ML, like Java and C# is not a dynamic
language. ML lacks a feature that Ruby has: method_missing. To
understand why this is important, let me briefly explain type
inferencing.

Type inferencing works by examining the methods actually used by a
particular variable. This method signature (duck type) is compared to
the declared method signature of known classes. From this, a set of
all known classes that could legally be assigned to the variable is
inferred.

Method_missing throws this all to heck. A class with method_missing
might implement any duck type, and so has to be added as a possibility
to every variable. That's why dynamic languages (like SmallTalk) that
use type inference still require some type hints in some
circumstances.

Speed is only one advantage to a static typing system. In general,
static typing makes it easier (for programs as well as people) to
analyse programs that use it.