On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:

>    If the language were statically typed, I would know straight away what
>    type the parameter was and can look up, exactly, what it does and can
>    probably easily discern what it's role is.

i think that's a silly thing to say.  straight away, tell me what role this
function plays:

   void (*signal(volatile int x, void (*const y)(int )))(int );

??

and i don't think that's being unfair.  the reason is that static typing
builds up mountains of information for even mildly complex function
definitions.  there is a reason a program exists (cdecl) to decode them!  it's
very existence backs my assertion that little can be groked 'staight away'
merely by statically/explicitly typing function signatures.

in addition, languages like ocaml, while also statically typed, leave this
information out of the source while still be readable:

   let double x = x * 2;;

   let sum x y = x + y;;

   let factorial x =
     if (0 > x) then (raise Exit) else
     match x with
         0 -> 1
       | n -> (n * (factorial (n - 1)));;


notice - this is statically typed.  also notice the lack of explicitly encoded
typing - the compiler figures it out.

my point, in going down this tangent, is hopefully to point out what i always
point out in these threads - that people generally do not even understand what
it means to be statically (c is static ruby is not) or strongly typed (ruby is
strongly typed, c and java are not) and, furthermore, that having this
explicitly written by the programmer has nothing to do with the existence if a
feature in the language - taking ocaml's type inference as an example.

so, to drive it home further, you seem to think 'static' means 'explicitly
written by the programmer' - but of course that's not what it means.
fortunately, the 'explicit' route is available to you in ruby by simply
following certain pratices, either comment functions or cast arguments using
the 'class name as casting ctor pattern' used all over the place in ruby.  for
isntance

   def m a, b, c
     a = String a
     b = Integer b
     c = Float f

     ....
   end

now, that's not static, but it is explicit.  you can obivously follow this
pattern with user defined classes.

regards.


> Now, don't misunderstand me, I'm not advocating turning Ruby into a
> statically typed language.  I enjoy that Ruby has no "templates" (in the
> C++ sense) because every method is "templatized!"  The mere fact that C++
> has templates is testimony to the power of dynamic typing.

templates are not dynamic typing though - i'd say they are testimony to how
much of a bastard a strong/static/non-inferred type system can be and how
adding compiler features to do the work for us is essential.  note that
templates and any other sort of compiler inference feature __remove__ explicit
type info from the source!

> I'm just saying that static typing "ain't so bad," in that this is one
> problem I would not have had were I working with a statically typed
> language.

correct - you'd simply have different ones.

> I'm also looking for how people deal with this issue, since it surely must
> come up from time to time...

well, i showed one solution above.  there are plenty of others.

cheers.

-a
-- 
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama