From: Austin Ziegler <austin@...>
Date: 2003-11-20T14:52:44+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

On Thu, 20 Nov 2003 10:48:01 +0900, Sean O'Dell wrote:
> On Wednesday 19 November 2003 05:06 pm, Austin Ziegler wrote:
  [...]
> I've shared code with developers on both typed and untyped code
> bases, and ALWAYS it's the typed code that they have less trouble
> with
  [...]

I think that you're assuming a conclusion not necessarily supported
by the facts. First, did you actually read the Eckels article? If
you did, you would see that Eckels is also a proponent of *tested*
code. Thus, the developers would have a set of unit tests to run.
One of the main reasons that Ruby code *is* successful without type
checking is that it's part and parcel to see the code be well
tested. Testing is part of the Ruby culture.

Second, *why* did the untype-tested code turn into a sticky mess?
There are facts not in evidence here -- were the developers
unfamiliar with the untype-tested language? Was it a lower priority?
Were those developers given adequate training on the untype-tested
language? Did the developers chosen for such languages have good,
discipline programming practices (I suspect not) or were there
strong coding guidelines (again, I suspect not).

I suspect you're just using the terminology incorrectly, but Ruby
isn't an untyped language. It is very strongly -- but dynamically --
typed. What isn't present is method signature introspection beyond
arity and presence. As I said, there are cases when more than this
would be useful, but that's IMO/E a small subset of the universe of
programs for Ruby.

>> Managers *don't* know the upsides or downsides to static typing.
>> Most of them won't actually have a clue as to what the term
>> means. There are legitimate reasons to use C, C++, and Java.
>> Static typing isn't one of them, and I can't think of a single
>> manager in my past who would argue that it would be. Some
>> developers, perhaps, but they are also people who didn't have
>> exposure to dynamically typed object systems and languages.
> Managers are generally programmers who don't program as much as
> they look at code and try to help people design integration.

I don't know where you're working, but none of the companies where
I've worked have *managers* actually *ever* looked at the code that
I've worked on. That's been left for senior developers (in the role
of mentor or team lead), designers, and architects. As a team lead
and senior designer, I would happily put people to work using a
dynamically typed language like Ruby (or Python, but I have a strong
prejudice against Python's inconsistencies). But I'd also introduce
a rigorous test-first paradigm and make sure that my developers were
familiar with the language being used.

> They like typing because it helps them understand the code. Typing
> helps. Like it or not. I'm not saying Ruby sucks because it's
> untyped, I'm saying typing helps.

I think that TDD helps more than typing.

[...]

>> As Matz has said, there's no clean way to do this in Ruby at this
>> point. Simply doing name checking (whether interfaces or
>> inheritance) doesn't ensure compliance, so it actually buys us *
>> absolutely* nothing more than assuming we have the right object
>> to begin with.
> I agree there's probably no efficient way to offer guarantees. I
> agree doing something like that would be way too off-the-path for
> Ruby. But I don't think that a half-promise is useless.

I do, because it's not really a promise at all. It's a claim.
Ultimately, we still have to verify -- or potentially crash horribly
-- that the claim is true.

>> One of the things not mentioned there is that Ruby is also used
>> in the Amazon apparel store (see [ruby-talk:54605]). All of these
>> have been done *without* type checking.
> I have no idea how to refer to [ruby-talk:54605], but I'll assume
> that Amazon uses Ruby as the backend for their apparel store.
> That's good to hear, but it doesn't mean it can scale out to other
> things very easily. The larger it spreads out, the more typing is
> handy.

[ruby-talk:54605] refers to this mailing list and its archive
message number. Try http://www.ruby-talk.org/54605/ for the original
announcement and thread.

>> *shrug* I don't think that it's necessary. Most people I've
>> talked to have been convinced that Ruby's worth looking at
>> because of the deep object orientation.
> This is a baby-and-bathwater issue. I still HATE that I can't
> control when objects die and that there's no destructor. Yes,
> garbage collection is nifty. Yes, I use yield now for doing
> cleanup, and it serves as a replacement, but in the year or two
> I've been programming in Ruby, I still hate that objects just hang
> around until the collector gets them, and I hate that all I get is
> a finalizer.
> 
> I LOVE Ruby, but I don't love that part, and probably never will.

I far prefer the advantages that garbage collectors give me. I don't
like having to deal with my own allocation and destruction. It might
be useful to have a concept like:

  GC.mark(object)

That marks the object invalid, but that's made slightly difficult
because there's no "real" way to access the raw object without a
reference.

>> A NOOP still costs performance. Further, since most things can be
>> redefined at runtime (there are very few keywords in Ruby), it's
>> not exactly something that can be turned off.
> I think the performance issue is blown out of proportion. Code
> gets added with each release that adds more to the code base and
> does far less than what a type checking mechanism would.

Most of those changes have narrower impact than what a type checking
mechanism would involve.

> Which is a curious trait that I don't share. And since, save for
> my occassional ranting threads, there is little traffic in this
> newsgroup/list, I am wondering if perhaps I'm just not "getting
> it" here and should move on to something else.

Um ... the list has about 3,000 messages a month. We're already at
about 2,200 messages for November. That's not "little traffic."

> When did the Ruby community become so hostile? I remember the last
> couple of discussions I had, they were energetic but polite, and
> now it seems like a war zone.

You have the unfortunate happenstance of defending a position that
has been discussed to death, and recently. Ruby with type checking
is not Ruby. I strongly suspect that in *most* cases, where people
want type checking, other techniques could fill in nicely without
making the code brittle. Test-driven development is one such
technique. Design by Contract is another.

I'm not hostile to you, by the way, I am hostile to the idea of
importing something that doesn't really add anything to Ruby for
specious reasons. Part of the reason that you're confused by the
dichotomy that I hold is that if I want a contractual guarantee, I
want it to be rock-solid. I don't want it to be a useless promise
that I have to check behind *anyway*. 

> If you folks are dead-set in your ways and look unkindly upon
> people who suggest that Ruby change and grow out off the beaten
> path a little, just say the word. I'm a free soul here, I'm not
> signed up for anything in particular.

What's being discussed isn't a little growth. It's a radical change
in direction if it's to be a useful change, and an unnecessary thing
if it isn't.

> I like Ruby, and I think a lot of it is smart, but because it's
> free and flexible, not because there's a hardened core of zealots
> who defend it from change at all costs. This seems silly. I got an
> anonymous comment on my RCR from someone calling my RCR "static
> typing."  That's getting ludicrous. What is that about? Is this
> what the community is boiling down to?

Note that the people who read your RCR on RubyGarden may not read
ruby-talk. The Ruby community isn't monolithic. Nor am I trying to
defend Ruby from change. I'm trying to ensure that such change is
useful.

> Lighten up folks. Take my RCR and comment on it until it works.

I don't think your RCR will *ever* be workable as part of the core
language. It asserts a promise -- that need not even be kept,
leaving us exactly where we are today. It's rather like the
prototypes in Perl ($@$%) theoretically guarantee that the
parameters will be passed as scalar, array, scalar, and hash, but
IIRC you *still* have to do special work with non-scalars. It buys
you nothing and is merely confusing in the end.

>> No, I don't like what you've proposed. Propose something that is
>> useful and I can see supporting it. So far, you've suggested
>> something that does not add value or hasn't been done by others
>> (namely Ryan Pavlik's metadata module).
> Is that the Metatags module he has in RAA? I thought that was more
> of a documentation thing that would be useful by parsers other
> than Ruby itself? I kind of remember something about that. It was
> a YAML thing, was it not?

No, not YAML. But that's the one, and it is sort of documentation.
He's set it up so that it can be queried by programmers using Ruby,
though.

> I don't think it's the same thing. I think it's also dependent on
> the developer keeping the code in sync with the metatags. I could
> be wrong.

It is dependent for such. It's also string-based, which is one of
the reasons that I find it unusable.

> Also, I think you are just disagreeing with me to disagree. Not
> once have I heard a suggestion to alter my idea to make it work.

Because, IMO, it *cannot* work. The best option for this RCR is to
die. Propose, perhaps, that DbC become part of Ruby, or that there
be a cleaner way of making this information available in the Ruby
core, but I don't know what the "right" answer is offhand. What I do
know is that I *don't* need static typing or interface checking in
the programs and libraries that I've written for Ruby.

> It's not set in stone. It's yours, it's Matz's, it's everyone's
> idea now. Talk and make it work. Off my ass now, please. You
> understand me, the idea is written up as an RCR. Go comment on it
> constructively.

IMO, there is no constructive statement to be made for it. What I'm
trying to do is convince you either (a) to make a proposal that
*can* be worked with or (b) to understand what can be used in place
of type checking of any sort in Ruby.

-austin
--
austin ziegler    * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
                                         * 00.52.26