# "stereotyping"

**URL:** <https://rubytalk.org/t/stereotyping/8947>\
**Category:** ruby-talk\
**Created:** [20 November 2003 05:54 UTC](https://rubytalk.org/t/stereotyping/8947 "2003-11-20T05:54:10Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_Campbell1](https://avatars.discourse-cdn.com/v4/letter/m/e274bd/32.png) [@Michael\_Campbell1](https://rubytalk.org/u/Michael_Campbell1)\
**Post date:** [20 November 2003 05:54 UTC](https://rubytalk.org/t/stereotyping/8947/1 "2003-11-20T05:54:10Z")

</div>

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  
> [http://companion.yahoo.com/](http://companion.yahoo.com/)

---

<div class="post-metadata">

**Author:** ![Joel\_VanderWerf1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Joel\_VanderWerf1](https://rubytalk.org/u/Joel_VanderWerf1)\
**Post date:** [20 November 2003 06:24 UTC](https://rubytalk.org/t/stereotyping/8947/2 "2003-11-20T06:24:15Z")

</div>

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.