From: Sean O'Dell <sean@...>
Date: 2003-11-20T08:19:08+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

On Wednesday 19 November 2003 03:00 pm, Austin Ziegler wrote:
> On Thu, 20 Nov 2003 05:48:37 +0900, Sean O'Dell wrote:
> > On Wednesday 19 November 2003 12:04 pm, Austin Ziegler wrote:
> >> On Thu, 20 Nov 2003 02:43:31 +0900, Sean O'Dell wrote:
> >>> Then don't specify a type for your arguments. Some people need
> >>> it, some people don't.
> >>
> >> Who *needs* it? And why? Immediately, the classes of applications
> >
> > I do. I almost didn't choose Ruby because of the lack of type checking.
> > I am primarily a C++ programmer. My guess is you're not hearing the
> > argument of scores of C++/Java programmers because they're not here,
> > because Ruby has zero type-checking.
>
> Likely not. Because if you're looking at choosing a scripting
> language based on its type-checking, you're excluding the vast
> majority of modern scripting languages including Perl, Python,
> JavaScript, and Ruby.

Exactly my point.  People are sticking with C++ where they could really 
benefit from moving to a script language like Ruby, or they're learning Java 
and they're stuck being C++/Java programmers.

> > I mean that in all seriousness.
>
> I grant that you mean that in all seriousness. But in doing so,
> you're not wanting Ruby. And I mean *that* in all seriousness.
> Interface publication and type checking are two different things.

Not really.  Interface declaration, and type checking in an OO environment 
performed the exact same task: telling code what an object can do.

> > People don't fiddle around arguing with others, generally, they
> > just walk away. I have never said a word to anyone in the Python
> > group about what could make Python better because there's too much
> > wrong with it to begin with. That's my opinion of Ruby right now.
> > I love it, but I think there are things like lack of type checking
> > that are making people go "ah screw it" and just move on.
>
> Again: consider the words of Bruce Eckels. The man knows what he's
> talking about and is amazed by the power of not statically type
> checking. It's saved him loads of work. You want to add the work
> back *into* Ruby development. Optionally, I grant, but part of what
> a language designer like Matz must consider, is what changes like
> you're talking about would mean to the "culture" of the language. If
> people start using an "optional" method signature mechanism for type
> name enforcement, then that changes the assumed and actual
> dynamicity of Ruby. I suspect that the number of people thinking "ah
> screw it" are few and far between and instead are feeling liberated
> from having to specify types unnecessarily.

The programmers who jump into Ruby, yes.  Their managers, no.  There are 
requirements in the real world that go beyond "what feels good" and some of 
it has a basis in reality.  Being able to ask what interface an object 
implements does a lot to make up for bad documentation and crazy error 
messages.  On large, multi-developer projects, and with poorly documented 
libraries, this gets proven every single day.  Type checking, in whatever 
form it takes, helps a LOT.

> Consider generics in Java (templates in C++). These effectively
> introduce the sort of dynamicity that is found in Perl, Python, and
> Ruby. Instead of having to do:
>
>   int max(int x, int y) { return x >= y ? x : y }
>   float max(float x, float y) { return x >= y ? x : y }
>   double max(double x, double y) { return x >= y ? x : y }
>
> You can do:
>
>   def max(x, y); x >= y ? x : y; end
>
> I know which I would prefer, and C++'s move toward generics is a
> halting step toward that step.

I loath templates.  But I know what you mean.

I am not an advocate for strong static typing.  I only advocate a reasonable 
assurance that an object implements a certain interface.

> >> that *need* this are (1) RPC-based programs that are dynamically
> >> discoverable, and therefore need cross-language inspection and
> >> (2) interface builders (a la Visual Basic "Property Inspectors").
> >> I can't think of any other class of application that *needs* this
> >> sort of meta data. I fully support being able to have this
> >> information available, say:
> >
> > Then you're not thinking hard enough about it. I can't force the
> > notion that type checking is useful if you really don't want to
> > listen.
>
> It's not that I don't want to listen: it's that type checking
> doesn't help in the real world. Ruby is used in a number of real
> world large-scale projects.

No, it is not.  Perhaps one day.  But not right now.  Java and C++ own that 
distinction, and I think if called the conglomeration of scripts written in 
Perl that I've seen thrown together in one directory a "project" then I think 
Perl is a runner-up.  Perhaps if you could all the interface code that PHP 
has generated, it would also be up there somewhere.  Ruby is used in some 
fair-sized projects, but I can't think of a single large, successful one 
right now.  Python has some doozies, though.

I really think doing some form of intelligent, flexible interface checking 
will put Ruby a notch up in a lot of C++/Java developer's eyes.  It won't be 
static type checking, but you can bill it as a suitable replacement, and I'm 
sure that'd be good enough for most water-cooler discussions.

> > No, documentation is not sufficient, especially since there is so
> > much code out there that is NOT documented. It would be much
> > easier to provide a typing mechanism that could at least report
> > which interfaces an object provides. Developers are more likely to
> > take advantage of that than they are to provide documentation.
>
> *shrug* If you want to think that static type checking is really
> going to help, that's your call. But it won't.

Listen.  I have said several times that static type checking isn't what I 
want.

> > Well, clearly the hierarchy is not designed to report properly
> > which interface StringIO implements, which is sort of my point. If
> > there were an abstract IO interface, StringIO could declare itself
> > an implementation of that interface, and methods that required
> > that interface would then have very informative error messages for
> > developers who passed it an non- conforming object.
>
> Useless runtime processing.

Listen.  My thoughts on this were already written.  I said it could be shut 
off at runtime.

> >>> It saves a lot of code and headaches when you can just ask "does
> >>> this object implement this interface?"
> >>
> >> Why do you need to ask unless you're implementing one of the
> >> cases that I pointed out above? Look at a lot of Ruby code out
> >> there: it *assumes* that the object provided implements the
> >> interface -- and it documents it as such.
> >
> > That is my point exactly. The assumption is already there. The
> > flexibility is already lost. You MUST provide a certain object
> > which provides a certain interface, or you end up with a deeply
> > embedded error, instead of an informative one pointing to your own
> > code.
>
> Incorrect. You might want to look at various libraries to see how
> they handle this stuff. Some do it through custom exceptions. Some
> do it early (a la Text::Format#hyphenator=).

That gets tedious, and it's not something I would be proud to heft onto the 
shoulders of all library developers.

> >>> You might not find it useful, but others definitely do.
> >>
> >> Mostly people new to Ruby recently from Java. Seriously.
> >
> > No. People experienced in both. I've programmed for Ruby for a
> > year or so now and I still wish for some type checking now and
> > then, when I'm digging around in someone else's code trying to
> > figure out what parameters they expected.
>
> I tend to open the code and look at it.

That's you.  Don't make the assumption that performing such a task is fine for 
everyone.  That's not a language feature, that's a personal habit.

> > I don't take being called a C++ or Java programmer as an insult. I
> > take it to mean that you don't, or haven't, programmed in either
> > enough to see type checking as a blessing, not a curse.
>
> Obviously, you're not speaking about that which you know. I
> recommend against it. I've done plenty of C, C++, Java, and Pascal
> programming -- as well as truly strongly typed languages (Ada,
> PL/SQL). Ada provides type checking that is *truly* useful (and
> exceedingly annoying because of its inflexibility), not the
> half-assed crap you get in C and C++. I've had to write two to
> twenty times the amount of code in C/C++, Java, or Pascal to do the
> same amount of work in Ruby. Not only that, my Ruby handles more
> types than my equivalent statically typed code.

You know what Ziegler?  If you toss around insults, I'm simply going to ignore 
you.  Telling a man who's programmed for 20 years, the last 12 of which were 
in C++ that he doesn't know about C++ is extremely presumptuos and insulting.  
If you want to start talking to air, keep insulting me.

> >>> Being able to query for the signature of an interface, with some
> >>> syntactic sugar to allow parameters to require them (optionally)
> >>> is very much, to me, The Ruby Way; fearless and visionary. This
> >>> should make everyone happy; people don't lose their flexibility
> >>> and we get all the type checking anyone should need.
> >>
> >> Once again: ancestry/name checking is not type checking. Neither
> >> is method checking (#respond_to?). Ruby divorces type from class,
> >> which is something that C++ doesn't do, and Java users "sorta"
> >> get if they think about interfaces.
> >
> > Terminology issue. Okay, let's call my promotion "interface
> > declaration." That's all I advocate right now.
>
> Still don't like it. I'd accept method signature publication that

Fact is, it doesn't seem like you like anything I say, so I think my thread 
with you is at an impasse.

	Sean O'Dell