"stereotyping"

ruby-talk
1

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/

2

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.