Re: "stereotyping"

In article <[e-mail]>,
Sean O'Dell <[e-mail]> wrote:
: 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.

That's the inverse of the Ruby Way.

If I want to be inclusive, I use less-specific features, I don't
require things I talk to to adhere to large, and
often-unnecessary, APIs.

For instance, let's say I have something which reads a file.

    def do_something(filename)
        foo=File.open(filename,"r")
        data=foo.read
        process(data)
    end

That only takes one kind of thing: a filename.  Suppose I wanted
to make it be able to read from a pipe, too.  Let's refactor it to
take an IO object as input:

    def do_something(input)
        data=input.read
        process(data)
    end

That's a happy thing, it also lets you work on StringIO objects,
simply because all it depends on is the "read" interface.  There's
no onus on the objects you pass in to support anything more than
read(), nor should there be.  (T. Onoma's "duck signature"
proposal comes to mind somehow.)

Oh, but you can make it even more inclusive, by using a more
general interface to the data:

    def do_something(input)
        data=""
        input.each do |li| data << li end
        process(data)
    end

Now it works on file handles, streams, arrays, regular strings,
and StringIO objects!  It's amazing how powerful you can make
something if you're just careful about which interfaces you
choose.  This is the kind of thing that makes people describe Ruby
as a "beautiful" language.

Now, granted, that last is likely to be slower, but that's a
tradeoff you have to make (and it certainly makes my point for
me): if you want things to be really general, you might have to
give up something else.

: > 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.

It 's probably fair to say that the major audience for the
development of Ruby as a language is the Yukihiro Matsumoto
community.  The fact that it's useful to anyone else is merely our
good luck.

Why should Person A do something that Person B suggests, which
otherwise doesn't benefit Person A's life, merely because Person B
thinks that Person C, an otherwise uninterested third party, might
be interested in Person A's thing?  I think that's the whole point
behind this big war, which everyone (bar Matz himself) seems to be
overlooking.

: 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."  

'scuse my bluntness, but to hell with that.  Project managers
don't care about theoretical features: they care about RESULTS.
The best way to promote Ruby isn't to add a billion features to
the language; it's to write great software in it, and to show that
the it's great software.

For example: I'd wager that the biggest thing helping to promote
Python isn't its OO capabilities, or its flexibility, or anything
like that.  The single biggest thing promoting Python is BitTorrent.

Come up with something that gets Ruby as ubiquitous as BitTorrent
has made Python, and you won't need to worry about interfaces or
any other managerial bullet-point list items.

--Dave