From: matz@... (Yukihiro Matsumoto)
Date: 2003-11-21T07:04:38+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

Hi,

In message "Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )"
    on 03/11/21, dblack@wobblini.net <dblack@wobblini.net> writes:

|I'm not big on the "Just Do It" stuff (I boycott Nike actually), so
|you'll have to forgive me for not Just Accepting It.  (Very uppity, I
|know :-)  In any case, I think it might be useful to clear a few
|cobwebs and look at this in its most distilled form.  Here I go:
|
|If this statement is true:
|
|   Ruby should include a type-checking framework.
|
|then one of the following two statements is also true:
|
|   1. No programming language without a type-checking framework
|        should exist.
|   2. It is acceptable for one or more programming languages without
|        type-checking frameworks to exist, but Ruby should not be
|        one of those languages.
|
|There is no third possibility; that is, given the premise, the only
|two possibilities are that #1 is true and that #2 is true.
|
|Now, if #1 is true, then Ruby is, and always was, a bad idea.
|Everything that has been done with it is tainted and moribund, because
|it should never have existed in the first place.  I find the evidence
|to the contrary compelling, and therefore reject #1 out of hand.
|
|That means that #2 is true (again, given the original premise).  This,
|in turn, means that at some point, we will reach a state of
|equilibrium where (a) one or more languages exist which do not have
|type-checking frameworks, and (b) both the existence of those
|languages and their lack of type-checking frameworks will be deemed
|acceptable.
|
|And this, in turn, leads me to wonder: if we're going to reach that
|point some day anyway, why not just decide that we've reached it now,
|with Ruby?

Interesting logic.  But it's not good enough to persuade Sean (and me).
Can I summarize my opinion and feeling toward Sean's idea:

  * we have had many many people requiring "static typing" in Ruby.
    They were basically either ignorants or trolls.  This is the
    reason why Sean had so strong objection at the beginning.

  * Sean's idea is (or becomes) not so-called static type checking.
    It's interface checking.  So we have no reason to refuse it like
    other "proposal".

  * Optional interface checking can produce better messages than
    simple NoMethodError.  This is a good thing.

  * When I hacked tDiary plugin, I had hard time understanding
    existing tDiary code, because it's kinda hard to distinguish types
    of arguments, and it was not convenient to put "printf" in the
    server-side program.  This kind of interface checking might help
    me; but plain API document would do too.

  * We have two challenges to implement interface checking.  The one
    is proper design of interface.  Sean wrote a new proposal in
    [ruby-talk:85888].  But I don't like its appearance (my personal
    feeling).  I have no idea what is good interface design.

  * The other is implementation.  Considering Ruby's dynamic nature,
    the interface check would be done at run-time.  Since all of us do
    not want the serious performance degrade, interface checking must
    be implemented efficiently.  But I have no idea how to do it.

In summary, "interface checking" (not static type checking we had seen
before) is a good thing.  But I'm not sure it's good enough to put in
the future Ruby, where API document might help, and where we have two
challenges above.

							matz.