Let me just point out that I am NOT ADVOCATING STATIC TYPING.  I don't think
ruby should force users to static type.  I am also not advocating any
changes whatsoever to the language Ruby with one exception and that is
multiple assignment which I don't see any need for.  I could, of course, be
wrong and if anybody knows a good example where multiple assignment makes
things easier I could easily be persuaded that it is useful.  I guess the
only reason for preserving multiple assignment that I can think of is to
preserve idioms like x = x + 1 which as pointed out is different from
x.+(1).  You could of course make x = x + 1 translate into x.+(1) as a bit
of syntactic sugar but that might lead to other problems.  Type inference is
something that would exist in the interpreter as some kind of error
messages.  You could turn it off if necessary.  I think that in most cases
it would be helpful in that it would catch real errors and I believe
although I can't prove this that any ruby program at all no matter how
dynamic would pass through the type inference system without any error
provided it did not have any statement that if executed would lead to an
error of the form "NoMethodError: undefined method 'foo' for someobject".
This of course is the error you get when you call a method on an object that
does not have that method defined.  

In a dynamic language like Ruby errors of the form I alluded to above are
the only type errors that I believe are in general possible.  I have a very
simple model for object oriented language like Ruby which is probably wrong
but I think ultimately captures the gist of things.  In Ruby or Smalltalk
you can only essentially do one thing and that is send messages to objects.
Everything in Ruby consists of essentially message passing.  Thus the only
error possible is that an object does not know how to respond to a message.
Of course my model is not completely correct because ultimately in any
language you have to actually "do something" at some point.  For instance if
you want to add 2 numbers or concatenate a string that is "doing something"
and not just message passing.  However the "doing something" part of Ruby
and Smalltalk only exists either at the lowest levels of the language that
are built in or in extensions to the language written in c.  You cannot
define how to add integers in Ruby and in fact you cannot even define
integers themselves.  Integers are low level constructs that must be built
into the language.  You can still even do type inference at this low level
because the number of low level object are finite and the built in
operations you can do with them are already defined like for instance adding
integers or concatenating strings.  So it always known that you can't add an
integer to a string and this can always produce an error before runtime
which currently does not happen.  For instance you can run the following in
ruby and it is valid

def ass(blah)
q = 4 + "fjdkjkf"
end

and I this error will be caught only at runtime.

There is only one thing wrong with type inference and that is that new
methods can be defined at runtime in Ruby which means it is possible that an
object does not know how to respond at compile time to a message but it does
know how to respond at runtime.  However I think this scenario happens very
rarely and if it was happening the programmer could just turn off type
inference.