From: dblack@...
Date: 2006-03-17T00:46:14+09:00
Subject: Re: Variant types

Hi --

On Thu, 16 Mar 2006, Stefan Haflidason wrote:

> Jim Weirich wrote:
>
>> If I understand correctly, it sounds very much like a static lanugage
>> concept, with little applicability to Ruby.  The problem with
>> implementing it is Ruby is not to open up variables to more than one
>> type (that happens automatically), but to artificially restrict the
>> variable to the explicitly listed types.
>>
>
> Can't a little restriction be healthy? In the lecture last week I could
> have, instead of using abstract classes in Java, used Ruby's dynamic
> typing to show that the property could already be set to be of any type.
> But is that freedom a weakness?

That's a bit like asking whether having strings is a weakness because
clarinets don't have them.  It's just a different design principle.

> What I don't have is an answer to the question, "How does the freedom of
> Ruby's typing system affect large-scale software development?". I enjoy
> programming in Ruby and have involved it in my final year project and
> every-day tasks. The freedom does make me a little nervous though, as
> unless I have misunderstood the ethos behind it, it seems to imply that
> those who use it must be proficient.
>
> Given the ease with which Ruby can be picked up, there are sure to be
> many people in the near future who put Ruby on their CV who have at best
> a simplistic understanding of its workings/use.
>
> I do not consider this to be a fault of Ruby; far from it. I do however
> forsee in my own future a discussion with a future manager where I
> suggest Ruby and will be required to exemplify Ruby's suitability for a
> large project.
>
> Without restrictions, and without the notion of contracts, what
> foundations could my answer be based on?

The evidence of people who've done it is one possibility.  Also, it's
important to remember (though you may not want to tell the future
manager :-) that the dynamism of Ruby is not something that can be
switched on and off.  Checking class/module ancestry is, I think,
comforting to some people.  But in the end, you send messages to
objects at a given point in runtime, and that's what it's all about.
Ruby doesn't really care whether you've checked the class name or not.
It's all about the objects.


David

-- 
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black