"stereotyping"

[Austin Ziegler]

On Wed, 19 Nov 2003 06:07:13 +0900, [email]dblack@wobblini.net[/email] wrote:

> On Tue, 18 Nov 2003, Thien Vuong wrote:

>> [email]dblack@wobblini.net[/email] wrote:

> Class name checking doesn't ensure needed behavior. [...]

It certainly doesn't. That doesn't mean that there aren't times when
name/ancestry checking isn't useful. Or that "publishing" a method's
signature isn't (at times) useful. Note: I'm not changing my
position in this debate -- I still think that, based on my last two
years of experience with Ruby, ancestry checking is of extremely
limited utility.

The main place that I use ancestry checking at this point is when
dealing with Ruby's built-in types -- Hash, String, and Array -- and
then only when I need to distinguish between types that have
identical method names but subtly differing semantics (e.g.,
Hash#each and Array#each). (The other place that I use it is when I
have a custom type that I absolutely want to be used. See Ruwiki and
Ruwiki::Config for an example.)

> what's happening is that I'm growing concerned because it seems
> that we're going through a flurry of popularity of #is_a?-based
> checks which pretend to be type checks but are not [...]

In some ways, this is a good thing -- it generally means that we
have new faces coming in :)

> In other words, what's going on in these class-checking practices
> is not type checking or strong typing but, in fact,
> _stereotyping_: that is, the belief that one can infer what an
> object can and will do from what it "is".

I like this term. A lot.

[...]

One of the things that I'd like to see is perhaps a change to
#respond_to? so that it's like this:

class Object
alias_method :orig_respond_to?, :respond_to?

def respond_to?(symbol, arity = nil)
if arity.nil?
orig_respond_to? symbol
else
(orig_respond_to? symbol) && (method(symbol).arity == arity)
end
end
end

It won't help in cases as was posted (e.g., accepts one argument of
varying types that you may want to behave differently), but I think
that Ara Howard's recommended technique in [ruby-talk:85479] is
probably better in the specific posted case.

-austin
--
austin ziegler * [email]austin@halostatue.ca[/email] * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 00.59.45

[Chad Fowler]

On Thu, 20 Nov 2003, Sean O'Dell wrote:

# On Wednesday 19 November 2003 03:57 pm, Eric Schwartz wrote:
# > "Sean O'Dell" <sean@celsoft.com> writes:
# > > It's a LOT better. For you, who knows the contract, no, it's the
# > > same thing. For a person using the library trying to pass in an
# > > unsuitable object, where the documentation is lacking (and that's
# > > MOST of the code out there, MOST code is completely undocumented) it
# > > results in an extremely useful and time-saving error message.
# >
# > It's not a lot better to me, because it's inconsistent. If, as you
# > propose, it should work one way in some cases (the person honors the
# > interface) and not in others (they don't), then you're right back
# > where you started!
#
# That's just how Ruby is, though. When you get an object, you never know what
# you're going to get with it. It's completely open-ended. This is just one
# way to clear the air.

But what Eric is correctly saying is that this doesn't clear the air. It
pollutes it with potential lies.

To Glenn Vanderburg's point, objective-c does interface checking in a way
that actually checks the interface--by grouping selectors into something
called an interface and then creating code that requires that the
*selectors are implemented*. This "interface Blah" idea you've proposed
isn't any better than checking for class, which I believe 99.9+% of us
believe does *not* guarantee an interface at all.

Classes and modules are convenient groupings of behaviors. They are
neither declarations nor contracts that guarantee that such behaviors will
persist in the objects that inherit from/include them.

#

# > Only it's worse, because now Programmer C sees that B promised to
# > implement interface 'foo', and now she has to figure out where
# > interface 'foo' is defined (probably in Library D, which she may not
# > even have installed) and is even more confused than before. And I
# > speak as someone who is continually irritated by having to troll
# > through, say, cgi.rb or dbi.rb to discover there's a method that does
# > what I want it to.
#
# How does Ruby work right now? Better than that?

Yes. Because objects don't lie about what their capabilities are. They
either respond_to? or they don't. class, module, or your "interface" have
nothing to do with the "contract" of the object.

[Michael Campbell]

> Well, I'm a senior developer/team leader. I have been considering
moving

> the team from "c" to ruby. However I have doubts that the

lower-level

> programmers can handle development without any type-checking

support. So

> we will probably move to either Java or c#.

What do you think you need to protect them /from/, exactly?


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
[url]http://companion.yahoo.com/[/url]

[Michael Campbell]

Sean O'Dell wrote:

> That's my experience. I love Ruby, but I just don't see a large

team working

> together without at least SOME form of type checking.

Does smalltalk have it? (Genuinely asking, I was under the
assumption
it did not, but I don't know smalltalk.) I do believe there have
been
some historically large smalltalk projects in the past, no?

>>However I have noticed that I need to "read the source" far more

often

>>than with Java libraries, and correctly interpreting the source

requires

>>experience.

>
> Thank you, that was my point. It's far easier to read the method

definition

> and see the types than to dig around in code. Good for smallish

projects,

> not efficient nor safe for large team projects.

I might note here that the fact he has to read the source wasn't
attributed to the fact there were no types listed. (It might have
been, but you're presuming it was, and I see no evidence of that
based
on the quote.)

>>I would love to do a comparative experiment myself; one team with

Java

>>and one with Ruby. Just not sure the boss would fund it :-)

>
>
> This was my point, too. At least with some type checking you could

show that

> Ruby would be at least as safe as Java, but with all the freedom of

Ruby.

> It's a win-win. Hard to argue against.

You're making the presumption here that type checking can be
correlated with "safety", which I'm not sure has been shown yet.




__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
[url]http://companion.yahoo.com/[/url]

[Sean O'Dell]

On Wednesday 19 November 2003 07:01 pm, Michael Campbell wrote:

> Sean O'Dell wrote:

> >
> > This was my point, too. At least with some type checking you could

>
> show that
>

> > Ruby would be at least as safe as Java, but with all the freedom of

>
> Ruby.
>

> > It's a win-win. Hard to argue against.

>
> You're making the presumption here that type checking can be
> correlated with "safety", which I'm not sure has been shown yet.

It's associated with "understanding" which is usually the predicate of
"safety." Understanding what a method expects helps you to call it properly.

Sean O'Dell

[David Naseby]

>-----Original Message-----

>From: Sean O'Dell [mailto:sean@celsoft.com]

>> You're making the presumption here that type checking can be
>> correlated with "safety", which I'm not sure has been shown yet.

>
>It's associated with "understanding" which is usually the predicate of
>"safety." Understanding what a method expects helps you to
>call it properly.
>

Understanding can be accomplished through investigation (irb, unit-tests)
and documentation, in addition to, or as an alternative to, type checking.

I'd encourage library developers to work on unit tests and documentation,
which aid me as a library consumer, as opposed to ramped up guard clauses,
which just get in my way as a library consumer.

David.

[Michael campbell]

Sean O'Dell wrote:

>>You're making the presumption here that type checking can be
>>correlated with "safety", which I'm not sure has been shown yet.

>
> It's associated with "understanding" which is usually the predicate of
> "safety." Understanding what a method expects helps you to call it properly.

How do the smalltalkers manage?

[Austin Ziegler]

On Thu, 20 Nov 2003 10:17:36 +0900, Sean O'Dell wrote:

> On Wednesday 19 November 2003 04:22 pm, Eric Schwartz wrote:

>> But it doesn't clear the air, it only pretends to, and only in
>> some cases.

> But, as with Ruby's dynamic typing, that's good enough. [...] It
> follows then that an interface declaration system would work the
> same way. [...]

An interface declaration system is useless unless it's used. I
frankly don't see ever using it in my libraries.

> This is why I feel the worry over half-implemented interfaces is
> unfounded. This isn't a static typing system, it's just a
> declaration system.

The same is achieved through Ruby without an unnecessary declaration
system.

> What I think is that so many people have expounded for so long on
> dynamic typing that it's hard to admit that perhaps there's a
> benefit to something resembling type checking. Apparently there is
> too much invested in dynamic typing to compromise.

Incorrect.

> I give up here, if that's the case. I never close my mind to
> anything, and it seems that most people here are simply closed to
> the idea of anything resembling type checking.

Wrong. The reasons for not thinking that your proposal is useful
have been discussed several times. It is not a value-add. If there's
going to be an interface declaration system, it should be (a) easy
to use, and (b) optionally enforce the contract. Your system doesn't
do (b) and that makes it even worse because it's got a nonzero
mental cost when the alleged promise is broken.

-austin
--
austin ziegler * [email]austin@halostatue.ca[/email] * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 22.56.08

[Clifford Heath]

Michael campbell wrote:

> How do the smalltalkers manage?

Couldn't say for sure, but I've never known a smalltalker who
worked as part of a team on a project of extended duration...
I'm sure that says something.

[Michael Campbell]

Clifford Heath wrote:

> Michael campbell wrote:
>

>> How do the smalltalkers manage?

>
>
> Couldn't say for sure, but I've never known a smalltalker who
> worked as part of a team on a project of extended duration...
> I'm sure that says something.

About them, or you? =)


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
[url]http://companion.yahoo.com/[/url]

[Sean O'Dell]

On Wednesday 19 November 2003 07:56 pm, Austin Ziegler wrote:

> On Thu, 20 Nov 2003 10:17:36 +0900, Sean O'Dell wrote:

> > On Wednesday 19 November 2003 04:22 pm, Eric Schwartz wrote:

> >> But it doesn't clear the air, it only pretends to, and only in
> >> some cases.

> >
> > But, as with Ruby's dynamic typing, that's good enough. [...] It
> > follows then that an interface declaration system would work the
> > same way. [...]

>
> An interface declaration system is useless unless it's used. I
> frankly don't see ever using it in my libraries.

Thus the optional component of the RCR.

> > This is why I feel the worry over half-implemented interfaces is
> > unfounded. This isn't a static typing system, it's just a
> > declaration system.

>
> The same is achieved through Ruby without an unnecessary declaration
> system.

No, it is not. Methods have no way of informing anyone of their needs
currently. Not without a lot of messy code.

> > What I think is that so many people have expounded for so long on
> > dynamic typing that it's hard to admit that perhaps there's a
> > benefit to something resembling type checking. Apparently there is
> > too much invested in dynamic typing to compromise.

>
> Incorrect.

No, I think I got it right.

> > I give up here, if that's the case. I never close my mind to
> > anything, and it seems that most people here are simply closed to
> > the idea of anything resembling type checking.

>
> Wrong. The reasons for not thinking that your proposal is useful
> have been discussed several times. It is not a value-add. If there's
> going to be an interface declaration system, it should be (a) easy
> to use, and (b) optionally enforce the contract. Your system doesn't
> do (b) and that makes it even worse because it's got a nonzero
> mental cost when the alleged promise is broken.

Read the RCR. It's entirely optional, and it's extremely simple. Too simple,
as someone pointed out.

Sean O'Dell

[Michael Campbell]

>>>What I think is that so many people have expounded for so long on
>>>dynamic typing that it's hard to admit that perhaps there's a
>>>benefit to something resembling type checking. Apparently there is
>>>too much invested in dynamic typing to compromise.

>>
>>Incorrect.

>
>
> No, I think I got it right.

The exact opposite might be said from someone with a largely dynamic
typing background. "What I think is that so many people have [used]
static typing for so long that it's hard to admit that perhaps
there's
a benefit to [not relying on it]. Apparently there is too much
invested in static typing to compromise."

That doesn't sound to me too far off the mark either.



__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
[url]http://companion.yahoo.com/[/url]

[Simon Kitching]

On Thu, 2003-11-20 at 15:54, Michael Campbell wrote:

> > Well, I'm a senior developer/team leader. I have been considering

> moving

> > the team from "c" to ruby. However I have doubts that the

> lower-level

> > programmers can handle development without any type-checking

> support. So

> > we will probably move to either Java or c#.

>
> What do you think you need to protect them /from/, exactly?

No, it's more to protect me!

It's to protect me from questions like:

"Hey, what kind of object is this method expecting? It isn't documented
anywhere and I can't understand the source code".

"Hey, I'm getting this message from the XXX library about do_foo not
existing on parameter bar. I must be doing something wrong. How do I fix
it?"

"Hey, I'm supposed to fix this library method. What parameters are
people allowed to pass to it?"

and the corollary question:

"Hey, your team isn't making much progress on this project, despite this
Ruby language you suggested. Why shouldn't I fire you?"

[Michael Campbell]

Simon Kitching wrote:

> No, it's more to protect me!

*chuckle*

> It's to protect me from questions like:
>
> "Hey, what kind of object is this method expecting? It isn't

documented

> anywhere and I can't understand the source code".
>
> "Hey, I'm getting this message from the XXX library about do_foo

not

> existing on parameter bar. I must be doing something wrong. How do

I fix

> it?"
>
> "Hey, I'm supposed to fix this library method. What parameters are
> people allowed to pass to it?"
>
> and the corollary question:
>
> "Hey, your team isn't making much progress on this project, despite

this

> Ruby language you suggested. Why shouldn't I fire you?"

I think it would be very illustrative to turn one of these guys loose

on a project with ruby and see what you get. You might be
presupposing problems will exist where they won't... or not. Won't
know till you try it though.

In very few cases have I just not found documentation where I needed
it; I haven't had to go into src code much at all (I can't really
remember a specific time, actually), and my only consternation so far

has been what I would consider dubious design choices, not typing
issues.

Ruby is the first language I've used that has this sort of typing, so

I'm still feeling my way around a bit, but I haven't found it a
hinderance in any way. (Nor, might I add, have I found this
wonderous
freedom that's been espoused, but I don't think I'm writing idiomatic

ruby yet, either; I suspect my ruby has a decided perl or java "feel"

to it still.)

Still, I've been programming professionally for close to 20 years
now,
so I do feel I have a handle on /some/ of the basics.


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
[url]http://companion.yahoo.com/[/url]

[David Naseby]

>-----Original Message-----

>From: Simon Kitching [mailto:simon@ecnetwork.co.nz]

>> What do you think you need to protect them /from/, exactly?

>
>No, it's more to protect me!
>
>It's to protect me from questions like:
>
>"Hey, what kind of object is this method expecting? It isn't documented
>anywhere and I can't understand the source code".

If the developer of the library was crap enough to leave the library
completely undocumented, what makes you think she will put in (optional)
type clauses?

>
>"Hey, I'm getting this message from the XXX library about do_foo not
>existing on parameter bar. I must be doing something wrong.
>How do I fix
>it?"

"Hey, I'm getting this message from the XXX library about parameter bar not
implementing the interface FooDoer. How do I fix it?" I really don't see
what's unclear about the exact error message, and why a more obfuscated
"interface" makes it clearer. This question is followed up with "What does
the FooDoer interface have to implement?". If the library developer was that
crap with documentation, why is the interface going to be more documented
than an exact message failure is self-documenting???

>"Hey, I'm supposed to fix this library method. What parameters are
>people allowed to pass to it?"

"Hey, this library method expects a
SomeLibrary::Interfaces::IFooUndocumented interface passed to it. What
parameters does IFooUndocumented expect?". An undocumented library is crap.
A documented library is good. This whole thread is trying and IMO failing to
suggest that type-checking, or type-verification, or something, will somehow
replace or compliment bad documentation.

>and the corollary question:
>
>"Hey, your team isn't making much progress on this project,
>despite this
>Ruby language you suggested. Why shouldn't I fire you?"
>

Can't answer this one at all :)

David.

[Austin Ziegler]

On Thu, 20 Nov 2003 14:31:37 +0900, Sean O'Dell wrote:

> On Wednesday 19 November 2003 07:56 pm, Austin Ziegler wrote:

>> Wrong. The reasons for not thinking that your proposal is useful
>> have been discussed several times. It is not a value-add. If
>> there's going to be an interface declaration system, it should be
>> (a) easy to use, and (b) optionally enforce the contract. Your
>> system doesn't do (b) and that makes it even worse because it's
>> got a nonzero mental cost when the alleged promise is broken.

> Read the RCR. It's entirely optional, and it's extremely simple.
> Too simple, as someone pointed out.

I did. It adds no value over and above what Ruby already has and
uses. You can say that the error messages will be better, but I
disagree. How is saying that "I expect a Socket" any better than
saying "I don't know how to deal with #accept"?

And *that*, Sean, is fundamentally why I disagree with this
proposal. It doesn't add value, and it makes promises that it can't
even come close to keeping.

-austin
--
austin ziegler * [email]austin@halostatue.ca[/email] * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 01.16.12

[Austin Ziegler]

On Thu, 20 Nov 2003 14:39:08 +0900, Michael Campbell wrote:

> The exact opposite might be said from someone with a largely
> dynamic typing background. "What I think is that so many people
> have [used] static typing for so long that it's hard to admit that
> perhaps there's a benefit to [not relying on it]. Apparently there
> is too much invested in static typing to compromise."
>
> That doesn't sound to me too far off the mark either.

What's interesting is that I haven't opposed the idea of type
introspection on methods -- I've advocated it for certain classes of
applications. I haven't even really opposed contract assurance
(e.g., Design by Contract).

I *have* opposed type checking that does neither.

-austin
--
austin ziegler * [email]austin@halostatue.ca[/email] * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 01.19.59

[Joel VanderWerf]

Michael Campbell wrote:

> Simon Kitching wrote:
>
>
>

>>No, it's more to protect me!

>
>
> *chuckle*
>
>

>>It's to protect me from questions like:
>>
>>"Hey, what kind of object is this method expecting? It isn't

>
> documented
>

>>anywhere and I can't understand the source code".
>>
>>"Hey, I'm getting this message from the XXX library about do_foo

>
> not
>

>>existing on parameter bar. I must be doing something wrong. How do

>
> I fix
>

>>it?"
>>
>>"Hey, I'm supposed to fix this library method. What parameters are
>>people allowed to pass to it?"
>>
>>and the corollary question:
>>
>>"Hey, your team isn't making much progress on this project, despite

>
> this
>

>>Ruby language you suggested. Why shouldn't I fire you?"

>
>
>
> I think it would be very illustrative to turn one of these guys loose
>
> on a project with ruby and see what you get. You might be
> presupposing problems will exist where they won't... or not. Won't
> know till you try it though.

That kind of experience would be interesting to hear about.

Another factor that might help: supposing you have a comprehensive test
suite and a test-first policy, you have another way of fielding
developer questions besides digging through source or looking at
(possibly out-of-sync) documentation: just tell your colleagues to look
at the tests.

If you consider the specification of your software to be the test suite,
then that is where you should look when you want to know "what kind of
object is this method expecting" or "what parameters...".

I've never worked with a group this way, but that's often the way it
works when I've forgotten how my own code behaves. When I'm confused, I
look at the canonical examples that are guaranteed to work because the
tests all pass. If there's not enough information there, then there
should be more tests. This is really more useful than static typing,
since it can also tell me which situations lead to which exceptions, or
other complex input-output relationships that are not explained by just
knowing input and output types.

> In very few cases have I just not found documentation where I needed
> it; I haven't had to go into src code much at all (I can't really
> remember a specific time, actually), and my only consternation so far
>
> has been what I would consider dubious design choices, not typing
> issues.

[Austin Ziegler]

On Thu, 20 Nov 2003 14:40:04 +0900, Simon Kitching wrote:

> On Thu, 2003-11-20 at 15:54, Michael Campbell wrote:

>> Simon Kitching wrote:

>>> Well, I'm a senior developer/team leader. I have been
>>> considering moving the team from "c" to ruby. However I have
>>> doubts that the lower-level programmers can handle development
>>> without any type-checking support. So we will probably move to
>>> either Java or c#.

>> What do you think you need to protect them /from/, exactly?

> No, it's more to protect me!

There are alternative mechanisms for doing that, though.

> It's to protect me from questions like:
>
> "Hey, what kind of object is this method expecting? It isn't
> documented anywhere and I can't understand the source code".
>
> "Hey, I'm getting this message from the XXX library about do_foo
> not existing on parameter bar. I must be doing something wrong.
> How do I fix it?"

If this is in a core or extension library, this is a problem. If,
however, it's in a library written by your team, this is a huge
problem. Some of this could be fixed by tests.

> "Hey, I'm supposed to fix this library method. What parameters are
> people allowed to pass to it?"

Where's the design document? Where's the test cases? Why isn't the
library method documented in the first place?

> and the corollary question:
> "Hey, your team isn't making much progress on this project,
> despite this Ruby language you suggested. Why shouldn't I fire
> you?"

I think that's an unnecessary fear. Honestly.

-austin
--
austin ziegler * [email]austin@halostatue.ca[/email] * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 01.22.39

[Julian Fitzell]

Clifford Heath wrote:

> Michael campbell wrote:
>

>> How do the smalltalkers manage?

>
>
> Couldn't say for sure, but I've never known a smalltalker who
> worked as part of a team on a project of extended duration...
> I'm sure that says something.

Wow! That's quite the troll! - I think I'll bite.

As a smalltalker who has been working on the same project in a team at
work for 9 months and who has been contributing to open source projects
as part of rather large distributed teams for several years, I can
assure you that the fact that you've never met any smalltalkers who have
done so reflects more on who you've met than on who is out there.

I quick scan of [url]http://www.whysmalltalk.com/production/index.htm[/url] gives
you some idea of some of the many large scale applications deployed
using Smalltalk. These applications are used by companies like Chrysler
and FedEx as well as many large banks, insurance companies, etc. I
think we can safely assume that these applications are developed by more
than a single individual and over an extended duration.

To touch on the broader issue, I don't need a static type to know what a
method expects. My method parameter might be called aWidget, for
example which tells me it is expecting something that behaves like a
widget. Then if I need more clarification, I can look at the code
(which is probably no more than 5-10 lines - smalltalk methods are
usually that short) and see what methods are called on it. Then I know
it's expecting an object that responds to those methods. If for some
reason, it still wasn't clear, I could easily put in a comment
explaining what was expected but I can't think of a time recently where
that has been necessary.

I can't say I've ever run into cases in Smalltalk where I can't
understand what a method expects because I don't have static typing.
And I'd laugh at anyone who claims Java code (for example) is easier to
read than Smalltalk - I don't need a Javadoc equivalent in Smalltalk to
understand the code.

Julian