Re: "stereotyping"

On Friday 21 November 2003 02:42 pm, Dave Brown wrote:
> In article <[e-mail]>,
>
> Sean O'Dell <[e-mail]> wrote:
> : Q: Okay. We have to look to code quite often in lieu of project
> : documentation, and normally we look to the description of
> : classes, and the declarations of function parameters to
> : determine how to make calls and to understand how classes are
> : designed that are unfamiliar to some of the programmers on the
> : team.  Type checking would help us to know what parameters are
> : used by certain methods at-a-glance, which saves us from having
> : to spend time studying source code to figure things out.
>
> Of course, the simple answer to that is to use
> properly-descriptive parameter names.

I know.  I agree, too.  Doesn't happen as often as I wish.

> It generally doesn't matter what something is made of--what
> matters is what it *is*.

I disagree here.  It's a nomenclature issue, I suppose, but I am personally 
only concerned about what an object does, not what it is.  I can't use an 
object passed to me that is a string, if it gives me no way to make use of 
it.  I need access, so to me the most important thing is what it does.

Also, objects do things in different ways.  I could have an object that is a 
Report object.  If it uses text files, great, that's easy.  If it uses MySQL, 
okay, let me go set up a table it can use somewhere, or make the connection 
to an existing one.  It's what it does that determines there is an issue.

But, then again, you can say that with something like an interface, you're 
making both statements.  Interfaces are immutable, and you can't partially 
implement one.  When fulfilled, you can say "this object is this" as well as 
"this object does this" pretty clearly.

> In other words, if it's Java you're looking for, you know where to
> find it.  Ruby "market share" isn't something I think is even
> worth considering.  It's a wonderfully handy tool and it makes my
> life easier, and that's all I ask of it.

Yeah, I know people feel that way.  The problem I have with that point of view 
is that not caring about market share sounds a lot like not caring about 
anyone outside the Ruby community.  Getting programmers to use Ruby is not 
about gaining market share, it's about being able to say "Ruby is here to be 
the best programming language we can make it, no more and no less."  If you 
decide that features from Java aren't worth putting in simply because Java 
has it, that's prejudice that I don't think is at the heart of Ruby.  Ruby is 
about adopting what works.  Interfaces work in lots of places.  Directing 
people away from Ruby to get a feature like this doesn't seem to me what the 
Ruby community historically has done.  It's packed with lots of cool features 
taken from here and there.  If interfaces can be done with finesse and makes 
Ruby stronger, it should be adopted.  As things progress, it seems like we've 
found a way to do it without a lot of back-breaking work which doesn't break 
Ruby now, and which also doesn't look like a third eye growing out of its 
elbow.  It could be just another quietly tucked away feature that gets used 
by some, ignored by others.

> I don't care what management thinks of Ruby: I only care about
> getting the job done.  When something needs to be done, I use
> whatever tools are at my disposal and are most effective.  Ruby
> doesn't need to be "promoted"; it just needs to be used.  Let it
> promote itself by demonstrating results.  Leave the bulleted
> feature lists to the likes of Microsoft Word.

Being able to put something on a feature list is not a reason to discount it, 
though, either.  It has value in itself.  If people have been asking for 
something, and you've found a cool way to do it that fits right in with the 
language, then you put it on the list.  But that's not WHY you do it, to put 
it on the list.  You do it because there are real reasons for it, and the 
reward is yet another really cool feature on the list.

Ask yourself: why does Ruby have iterators?  You could do loops lots of other 
ways.  It's there because it was the coolest, smoothest way that could be 
conceived of at the time and it endures today.

This is what I think we can achieve.  Something cool and smooth and which will 
endure and will make Ruby just that one little bit better.

	Sean O'Dell