Hi,

In general I agree with you that *contract* is really a good idea (I think
it is one of the Eiffel's pillar strengths).

However, for now, I am just thinking from the business case point of
view.  When I first learned Ruby, I did it the procedural way (as it is my
background as an engineer), and later to OO way, and finally I got the
very nice surprise that I actually have programmed in OO since the
beginning (since I was actually programming in the Object class.)

I think the same is true for people who are used to code in
C/C++/Java.  If the first time they see

    def func (a, b, c)

I think they will be scared to death (or at least, feel rather
uneasy).  Now, if their first program is

    def func (Float a, String b, Fixnum c)

I think it will be much more natural to them.  Only later, we will reveal
to them that all those "static type" are actually optional, and then they
can really start programming in "the Ruby Way". :)

Also, to sell Ruby to the corporate world, probably "staticly/strongly
typed" has more a buzzword quality (ala Java).

I don't expect everyone to agree with this, but I think it will be
beneficial to all of us if finally Ruby can really make it to the
corporate/business world.  To be able to achieve this, we need the right
approach, the right buzzwords, the right selling points, to steal the
hearts and minds of first the programmers, and then their bosses. :)

Regards,

Bill
===========================================================================
Jason Voegele <jason / jvoegele.com> wrote:
> While I certainly don't feel that such things should be a part of Ruby
> proper, a statically-typed language based on Ruby and Eiffel might be
> rather interesting.  However, rather than a strict class/type association
> that most languages adhere to, I think it would be more interesting to
> equate type with *contract*.  What I mean is that you could make a
> contract a first class language construct.  For example: