Asp Forum - Re: "stereotyping"

Michael Campbell

11/20/2003 7:07:00 PM

Sean O'Dell wrote:

> No has to just do it. But when people ask for something, it gets
annoying to
> hear over and over "but why but why but why." Why is not an
appropriate
> question anymore.

It might not be appropriate to you because you seem to feel that
there
have been answers to it already.

I'm guessing here that the people that ask now either haven't
accepted
that the answers that have been given to be valid.

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion....

16 Answers

Sean O'Dell

11/20/2003 7:44:00 PM

On Thursday 20 November 2003 11:07 am, Michael Campbell wrote:
> Sean O'Dell wrote:
> > No has to just do it. But when people ask for something, it gets
>
> annoying to
>
> > hear over and over "but why but why but why." Why is not an
>
> appropriate
>
> > question anymore.
>
> It might not be appropriate to you because you seem to feel that
> there
> have been answers to it already.
>
> I'm guessing here that the people that ask now either haven't
> accepted
> that the answers that have been given to be valid.

When people give their reasons, that's it. That's the reason. The line of
questioning tends to go like this:

Q = random programmer questioner
A = Ruby community answerer

Q: Does Ruby have type checking?

A: No.

Q: I need type checking. Will it ever have type checking?

A: Maybe, but we can't figure out how to do it right now so our official
answer is that you don't need it. If we figure it out, then your needs will
be considered valid. Why do you need type checking anyway?

Q: Because we find it helps us control our large team projects.

A: I don't agree that it helps you control your large team projects. Can you
offer more evidence?

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.

A: We always just read the source code, so that should be good enough for you.
Perhaps if you gave us another reason.

Q: Okay. When an unsuitable object is passed to a method, and that method
tries to call a method of the object that either doesn't exist or has a
different number of parameters than expected, an error occurs deep inside the
method and it's tedious figuring out how to fix what went wrong. Some form
of type checking would help us recognize our mistakes faster.

A: We always just read the source code where the error occured, unless it's a
C-extension object, so that should be good enough for you. Perhaps another
reason would convince us.

Q: Gee, alright, but I'm running out of reasons.

A: Thus you are close to realizing the friviolity of your request. If you had
a sufficient quantity of reasons, you could argue indefinitely, and therefore
win the argument. The fact that you are running out of reasons and are
leaving the discussion indicates that perhaps you don't really know what you
need. The Great Ziegler knows what you need. Or would you prefer to
continue discussing this?

Q: Huh? Okay, I think. Uhm ... well, we've been pushing to use Ruby on some
of our projects for a long time here, and the higher ups aren't crazy about
Ruby for a couple of reasons, and one of them is type checking. See, they
used to be programmers and they still know a lot about what we do, and they
also know the value of type checking, but they're not quite as willing as we
are to experiment a little. I think they may have a lot of money sunk into
the company or something. Just for the sake of argument, to promote its use,
having any form of type checking, even if it's completely circumventable,
would give us a way to assuage our superiors that Ruby would not become an
unmanagable tangle.

A: We have heard that argument before, and we will laugh at you now as we have
laughed at others before. HA HA! Don't try the pointy-haired boss argument
with us, apprentice. Away with you now! To Smalltalk or Python, we care
not! At least until we figure out how to implement some form of type
checking that we're satisfied is strict enough to crack diamonds on, then you
may return and we will gladly accept all of your arguments.

Okay, I'm just jabbing now. But in all seriousness, it really sounds like the
message around here is: "we don't want type checking, but we're trying to
figure out how to implement it, and so far we have rejected some attempts
because they were too soft for us because while we're really into no typing
at all, when we do implement type checking, it must be super-rigorous or not
at all, and until then your arguments for why you need type checking are
completely beneath contempt, although if we do ever figure out how to
implement a super-rigorous type checking system, then we'll give you what
you've been asking for."

Sean O'Dell

Rasputin

11/21/2003 8:49:00 PM

* Sean O'Dell <sean@celsoft.com> [1144 19:44]:
> A: I don't agree that it helps you control your large team projects. Can you
> offer more evidence?
>
> 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.

You're assuming the guy who wrote the library methods used this
optional 'interface' extension. If he cant even be bothered to
document his library, why would he do that? Wouldnt a class
need to know in advance that it would be passed to an interface-aware
method?

This seems to be using interface implementation to flag a class
as suitable for use in a particular way. Thats just as much an agreed
protocol between the method and the argument as a respond_to? approach,
but respond_to? doesnt require such a fundamental change to the
language (and thats what it would have to be, if it was really to be
useful - I dont think an optional feature would please anyone).

D'd certainly like extensions to respond_to? so I could check argument
type and count (think someone posted that earlier?) - but that could
be mixed in, so I wouldnt be imposing this on those who didnt want it.

> Q: Okay. When an unsuitable object is passed to a method, and that method
> tries to call a method of the object that either doesn't exist or has a
> different number of parameters than expected, an error occurs deep inside the
> method and it's tedious figuring out how to fix what went wrong. Some form
> of type checking would help us recognize our mistakes faster.

But again, its less hassle to document your API than to do rigourous
argument checking.

It seemed like you were more interested in a way to know how an API
will use your object. Why not send in a probe?

Pass a custom object in that has a method_missing? method that does
a ludicrous amount of debugging of how its called. That would tell you
how an API is actually using your object, what methods it calls and how.

Thats a back of a beermat approach, but I reckon that coupled with
some good unit testing frees you up from relying on the kindness of
strangers, at least a little.
Even if it only tests method name and argument count, that gives you all
an interface would, without any changes to the API you are using.

The difference is API probing can be done with existing mechanisms,
*optionally* and more importantly, they dont require both sides
of the method to play by the rules. Or reach a consensus :)

> Q: Gee, alright, but I'm running out of reasons.
>
> A: Thus you are close to realizing the friviolity of your request.

[snip]

The pissing contest is getting old now, and its just drawing out a
long thread to a longer one.

I think I share some of both sides viewpoint, but I dont want a
Java'ed Ruby, and it seems that this interface idea is coming from
that angle.

--
Boling's postulate:
If you're feeling good, don't worry. You'll get over it.
Rasputin :: Jack of All Trades - Master of Nuns

Sean O'Dell

11/21/2003 9:14:00 PM

On Friday 21 November 2003 12:48 pm, Rasputin wrote:
> * Sean O'Dell <sean@celsoft.com> [1144 19:44]:
> > A: I don't agree that it helps you control your large team projects. Can
> > you offer more evidence?
> >
> > 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.
>
> You're assuming the guy who wrote the library methods used this
> optional 'interface' extension. If he cant even be bothered to
> document his library, why would he do that? Wouldnt a class
> need to know in advance that it would be passed to an interface-aware
> method?

Because this is far simpler, and once started, cannot lapse. When he tests
his code, if he forgot to update the interface description, he'll get errors
that notify him. You can be mostly assured that the interface description
you see from a library is up-to-date, unlike documentation.

Convenience is a mighty strong catalyst for action.

> This seems to be using interface implementation to flag a class
> as suitable for use in a particular way. Thats just as much an agreed
> protocol between the method and the argument as a respond_to? approach,
> but respond_to? doesnt require such a fundamental change to the
> language (and thats what it would have to be, if it was really to be
> useful - I dont think an optional feature would please anyone).

The difference is: simply stating a class' purpose is easy. You do it once
and that's pretty much it. As you develop, though, the interface changes.
Keeping up with specific method documentation is much more labor-intensive.
If you have an interface description that you had to adhere to, you wouldn't
have the option of falling behind on updating it. Your code simply wouldn't
work until you did.

> D'd certainly like extensions to respond_to? so I could check argument
> type and count (think someone posted that earlier?) - but that could
> be mixed in, so I wouldnt be imposing this on those who didnt want it.

You can already do that now in Ruby, but perhaps an interface mechanism could
make that easier.

> > Q: Okay. When an unsuitable object is passed to a method, and that method
> > tries to call a method of the object that either doesn't exist or has a
> > different number of parameters than expected, an error occurs deep inside
> > the method and it's tedious figuring out how to fix what went wrong.
> > Some form of type checking would help us recognize our mistakes faster.
>
> But again, its less hassle to document your API than to do rigourous
> argument checking.

No, it's more hassle. To update a document, you have to open a different
file, and if you make a typo or just plain write it wrong, there is nothing
to stop you from doing so. Interfaces can be described in the same source
file as your class definition, so it's easy to find and update, plus, you
can't update it wrong, or your code gives you errors.

> It seemed like you were more interested in a way to know how an API
> will use your object. Why not send in a probe?

Because probes can sometimes cause damage, and the errors reported deep inside
may not be easily understood. It's a hit-or-miss proposition in there; some
people have no trouble diving in and reading someone else's code. I do it as
a last resort because I find it's a terribly inefficient way to debug.

> Thats a back of a beermat approach, but I reckon that coupled with
> some good unit testing frees you up from relying on the kindness of
> strangers, at least a little.

I just don't think that probing and unit testing alone does quite what I'm
proposing. My proposal provides a lot of assurance, a lot of understanding
right up-front, and I think will just plain make a heck of a lot of people
happy.

> Even if it only tests method name and argument count, that gives you all
> an interface would, without any changes to the API you are using.

Well, since classes can implement interfaces, the test can also check that
methods are being passed object that fulfill the interface contract. So, a
sort of type checking can be performed.

> The difference is API probing can be done with existing mechanisms,
> *optionally* and more importantly, they dont require both sides
> of the method to play by the rules. Or reach a consensus :)

We have probing already, and it functions for lots of people. Not everyone.
And not to the degree of ease and clarity some would like.

> > Q: Gee, alright, but I'm running out of reasons.
> >
> > A: Thus you are close to realizing the friviolity of your request.
>
> The pissing contest is getting old now, and its just drawing out a
> long thread to a longer one.

This was actually the start of it, as far as I know. You must have gotten
this post out of order, or read into things previously said that I didn't
catch.

> I think I share some of both sides viewpoint, but I dont want a
> Java'ed Ruby, and it seems that this interface idea is coming from
> that angle.

It is, it most certainly is, except for two things. One, it's not a
requirement, you can ignore it and never have to deal with it. Two, classes
that claim to implement an interface can still work dynamically and can add
their own methods. It's just an optional feature, not a whole new system
being imposed globally.

Sean O'Dell

Dan Doel

11/21/2003 9:51:00 PM

Sean O'Dell wrote:

>>But again, its less hassle to document your API than to do rigourous
>>argument checking.
>>
>>
>
>No, it's more hassle. To update a document, you have to open a different
>file, and if you make a typo or just plain write it wrong, there is nothing
>to stop you from doing so. Interfaces can be described in the same source
>file as your class definition, so it's easy to find and update, plus, you
>can't update it wrong, or your code gives you errors.
>
>
You always have to update documentation when you change something.
Having an interface checking
system doesn't mean that you don't have to document your code. So in
effect, having interfaces means
you have to update two different places when you make an interface
change (three, actually, if you
count the code that uses the interface), and there's more things that
can get out of sync.

Besides, with systems like RDoc you can make all documentation
annotations in your source and
generate the documentation from there, so it's really no more or less
convenient than having an
interface definition in your source, at least for documentation purposes.

- Dan

Sean O'Dell

11/21/2003 10:29:00 PM

On Friday 21 November 2003 01:50 pm, Dan Doel wrote:
> Sean O'Dell wrote:
> >>But again, its less hassle to document your API than to do rigourous
> >>argument checking.
> >
> >No, it's more hassle. To update a document, you have to open a different
> >file, and if you make a typo or just plain write it wrong, there is
> > nothing to stop you from doing so. Interfaces can be described in the
> > same source file as your class definition, so it's easy to find and
> > update, plus, you can't update it wrong, or your code gives you errors.
>
> You always have to update documentation when you change something.

Not always. If you provide code to others and are responsible enough to do
so, sure. On team projects, documentation happens very sporadically. RAA is
full of non or poorly documentation code. It is a good habit to have, but
humans often don't keep up with as well as they should.

> Having an interface checking
> system doesn't mean that you don't have to document your code. So in
> effect, having interfaces means
> you have to update two different places when you make an interface
> change (three, actually, if you
> count the code that uses the interface), and there's more things that
> can get out of sync.

Or, you could argue, the interface description could serve as the source for
your API documentation. I'm going to add that to the wiki; the idea just
occurred to me. Automatic documentation generation would be extremely easy
if you had interface objects to query.

> Besides, with systems like RDoc you can make all documentation
> annotations in your source and
> generate the documentation from there, so it's really no more or less
> convenient than having an
> interface definition in your source, at least for documentation purposes.

That much is a plus, but the biggest problem I have with that is the same as
the problem I had with defining interfaces through classes: methods are
spread out by the code inside them. Browsing a class is not all that
pleasant because of that. Smaller source files aren't so bad, but when a lot
of code sits in a source file, everything gets really spread out.

Sean O'Dell

dagbrown

11/21/2003 10:38:00 PM

In article <200311201143.59231.sean@celsoft.com>,
Sean O'Dell <sean@celsoft.com> 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.

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

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.

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.

--Dave

Sean O'Dell

11/21/2003 11:06:00 PM

On Friday 21 November 2003 02:42 pm, Dave Brown wrote:
> In article <200311201143.59231.sean@celsoft.com>,
>
> Sean O'Dell <sean@celsoft.com> 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

Rasputin

11/23/2003 7:44:00 PM

* Sean O'Dell <sean@celsoft.com> [1115 21:15]:

> On Friday 21 November 2003 12:48 pm, Rasputin wrote:

> > * Sean O'Dell <sean@celsoft.com> [1144 19:44]:
> > This seems to be using interface implementation to flag a class
> > as suitable for use in a particular way. Thats just as much an agreed
> > protocol between the method and the argument as a respond_to? approach,
> > but respond_to? doesnt require such a fundamental change to the
> > language (and thats what it would have to be, if it was really to be
> > useful - I dont think an optional feature would please anyone).

> The difference is: simply stating a class' purpose is easy. You do it once
> and that's pretty much it. As you develop, though, the interface changes.
> Keeping up with specific method documentation is much more labor-intensive.
> If you have an interface description that you had to adhere to, you wouldn't
> have the option of falling behind on updating it. Your code simply wouldn't
> work until you did.

Right, but thats no different to enforcing a respond_to? and
arity check coupled with an assert. I'm not saying thats a better
way, just it gives you the same assurance (IMO) without
such a big change to the language.

> > But again, its less hassle to document your API than to do rigourous
> > argument checking.

> No, it's more hassle. To update a document, you have to open a different
> file, and if you make a typo or just plain write it wrong, there is nothing
> to stop you from doing so. Interfaces can be described in the same source
> file as your class definition, so it's easy to find and update, plus, you
> can't update it wrong, or your code gives you errors.

My main doubt about this is, unless I misunderstand it,
this only makes APIs easier to use if the author decides to
use interface declarations.
But the choice 'to doc or not to doc' is no different to
'to interface or not to' for a lazy sod (I speak as one myself).
Unless you enforce it across the language, which would get you
burnt at the stake, you've potentially forked the language and you may
not even see a benefit.

It seems to me that when working around lazy b*stards like
me, its easier to doc a third party library than to retrofit
interfaces onto it.

> > It seemed like you were more interested in a way to know how an API
> > will use your object. Why not send in a probe?
>
> Because probes can sometimes cause damage, and the errors reported deep inside
> may not be easily understood. It's a hit-or-miss proposition in there; some
> people have no trouble diving in and reading someone else's code. I do it as
> a last resort because I find it's a terribly inefficient way to debug.

I agree, and I have found several promising APIs unusable because the
documentation was non-existent. My point was there are ways and means in
Ruby that the typed languages dont have, that feel more Rubyish than
a bolt-on feature.
In this case (investigating an alien object) we can verify an
object passed as an argument( respond_to? and arity checks) has methods
we expect, and callers of our methods can also see how methods they pass in
are being used by us (by use of a probe object).
I dont think an interface check can do any more. Admittedly someone has
written 'this object is for Xing' on it, but 99% of the time knowing there
is a method doX(objectA,objectB) does that job. There are edge cases
(using RMI systems, etc) but personally I'd prefer to dissect the remote
object rather than trust a flag on it if I didnt trust the source - and if
I knew where it came from, I'd rather unit test it.

I've started talking personal prefs, so I'll stop posting after this -
thats my 2p, anyway.

> Well, since classes can implement interfaces, the test can also check that
> methods are being passed object that fulfill the interface contract. So, a
> sort of type checking can be performed.

But thats no different from probing the objects you are passed as arguments.

> > I think I share some of both sides viewpoint, but I dont want a
> > Java'ed Ruby, and it seems that this interface idea is coming from
> > that angle.

Incihentally, my opposition to this isnt 'not invented here', its simply
that interfaces in Java *increase* flexibility, whereas in Ruby they
seem to be a restriction.

--
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain
Rasputin :: Jack of All Trades - Master of Nuns

dagbrown

11/24/2003 9:12:00 PM

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.

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

Sean O'Dell

11/24/2003 10:45:00 PM

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

comp.lang.ruby

Re: "stereotyping"

Michael Campbell

Sean O'Dell

Rasputin

Sean O'Dell

Dan Doel

Sean O'Dell

dagbrown

Sean O'Dell

Rasputin

dagbrown

Sean O'Dell

x Login to ForumsZone