On Monday 24 November 2003 01:12 pm, Dave Brown wrote:
> In article <200311211505.55669.sean / celsoft.com>,
>
> Sean O'Dell <sean / celsoft.com> 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.

I agree, which is why for my own personal use, I'm going back to something 
akin to what I wrote up in my first RCR.  Simple type tag agreements.

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

Yeah, and it's great with built-in types because we know them to be somewhat 
standard so we can depend on them.  There's no need for type checking when 
there's only a handful few types people could possibly pass in; just handle 
them all, even if you just throw a nice error saying you don't handle that 
type.

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

This sort of inward-focus has changed my view of Ruby.  I suppose it's this 
sort of culture which will bear for us the next generation of programming 
language, but it also has me backpedalling in a few areas.  It's good to 
experiment and be different, though; it breeds ideas.  Ruby is LOADED with 
ideas.

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

It depends if Person A sees the truth in what Person B is saying, and if 
Person A cares to interest Person C.  Clearly, in this case, Person A (aka 
Matz) does not care to interest Person C, whatever the truth might be.

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

What's ironic here is that what they use in actual practice (the dominant 
paradigm right now) is type checking.  My proposal wasn't to actually add 
type checking to Ruby, but to convince project managers that there was a 
sufficient mechanism to give them the advantages they seek with type 
checking.  Or at least, assuage their fears that leaving type checking behind 
was a giant ball of hair ready to choke them and their budget.

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

But then, the goal here isn't to promote Ruby.  Ruby is for the Ruby 
community, not everyone else.

	Sean O'Dell