From: Austin Ziegler <halostatue@...>
Date: 2005-05-31T03:11:56+09:00
Subject: Re: Intellisense and the psychology of typing

On 5/30/05, Richard Cole <rcole@itee.uq.edu.au> wrote:
> Lothar Scholz wrote:
>> Sometimes i think that the missing typeing eats up very much of
>> the time that is saved by being typeless as Code is much harder
>> to read and understand. That's why i simply can't understand
>> people who are against "optional" type declarations.
> Me too. Ruby is a great language and it has given birth to a
> really great collection of libraries, but I think that a little
> type information goes a long way; both in helping people who are
> reading the code (perhaps in the form of facilitating IDE
> annotations), and helping the compiler. Some RubyDocs seem to have
> type declairations, e.g. RMagick, does anyone know off hand how
> these come about?

These are probably noted by hand.

> In this thread someone mentioned an example of some code
> containing a function that takes either an int, or a hash of
> strings to ints. That sounds like a case for function overloading
> to me, aka

> def do_something(a: Int): String ...
> 
> def do_something(a: (String, Int) Hash): Int ...

No, thank you. This is Not Ruby. This is precisely why I don't
*want* type declarations in Ruby; it's ugly and stupid.

Type *hints* are something else, but should be applied indepenently
of the method declaration.

> Of course everyones favorite trick it to stick Ints and Strings
> into the same array, which, in my book, leaves you with an Unknown
> Array, Unknown being the type of your good old dynamic language
> object on which you can call any method (possibly getting a method
> not defined exception). Yes, type systems and type inference is a
> can of worms.

Sorry, but that's no better than Java's horrid hack of casting to
Object. If you have to cast, you're not dealing with a real dynamic
language. Sorry, but you don't want Ruby if you want this.

> One argument against a little type information is that: Oh, it's
> too restrictive, [...]

No, that's why I document what the method is supposed to do, and
what the user is to expect. The rest of the paragraph is nonsense
once you get to the point where you understand that this is the
responsibility of documentation, not excessively strict type
notations. If I have type notations, then I run into the problem
that I have restricted users of my class and methods. If someone
else makes something that acts just the way that I want it to, why
shouldn't they be able to use my methods just because I was arrogant
(stupid?) enough to restrict the method in the first place.

[...]

> An example of an implicit interface is that String and Array both
> provide an "each" function, but there is no explicit interface in
> Ruby that defines this shared property. Just some documentation
> (and a few language shortcuts the like the for loop).

And who needs that explicit interface? I sure as hell don't need to
say:

  class Foo implements EnumerableInterface
    ...
  end

Sorry, but that's not Ruby.

> On to my second point: a little type information helps the
> compiler. When skimming articles about optimising compilers for
> smalltalk I keep seeing comments like: such and such an optimiser
> couldn't infer that the inner loop operates over floats, so it ran
> 10 times slower than the equivalent C program.

When were these articles written? Frankly, modern compiler
technology -- and type inferencing -- will help far more than type
specification.

> There are times when you want to restrict the types to make the
> program run faster, e.g. programming an FFT, but who wants to
> leave the nice Ruby landscape and muck about in the C/C++ or Java
> dirt?

Those who want to make the program run faster.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca