[ruby-core:32639] Re: Proposal for Optional Static Typing for Ruby

Hi Loren,

On Sep 29, 2010, at 8:32 AM, Loren Segal wrote:

> Poor design can be a valid argument. However, it's hard to define =
whose design is the "poor" one when we're talking about a multi-paradigm =
language. A duck-typed system is not always the "right" design just =
because the target language is Ruby. There are many cases of good design =
in Ruby that use perfectly standard class-based systems with very little =
duck-typing-- I don't think it's fair to call them poor just because =
they don't use duck-types.

Here I will have to disagree with you...

I am reminded of an interview given by some of the early Twitter =
engineers where they explained that the reason for them to switch to =
Scala was that they found themselves creating an ad-hoc type system in =
Ruby, and that it didn't work very well. The problem, as I see it, is =
that while you *can* design aronud a class-based type system in Ruby, =
that doesn't mean you *should*. Ruby does not support class-based type =
systems very well. There are many, many other languages with much better =
support. However, you will find few languages that do duck-typing better =
than Ruby.

I think that if you can strive for more duck-typing and less reliance on =
classes, you'll have better Ruby code at the end of the day. If you =
would rather do a class-based system, there are probably better =
languages for you.

> But let me answer your question more directly by offering you a better =
example, one straight out of ruby-core's libraries. Consider String#[] =
(http://ruby-doc.org/core-1.8.7/classes/String.html#M000700), aka. =
String#slice, which has a whole host of overloads, 6 of them to be =
exact. This method would be a perfect candidate for actual overloading =
support. Do you think String#slice should be split up into #slice_index, =
#slice_range, #slice_regexp, etc.? I wouldn't think that would be a good =
API design.

Honestly? Well...yes. I'm constantly reading other people's code when I =
come across, for example, some variation on the use of slice that I'm =
not familiar with, and I find myself having to grab the documentation. =
Obj-C was cited as the inspiration for starting this thread. One thing =
you will find with Obj-C is that the method names are verbose. Very, =
very...very verbose. However, you will find few Obj-C programmers =
complaining about this (well...present company excluded). The reason is =
that your code becomes very self-documenting when the method names stick =
to the rule of "say what you do". I think the many forms of slice are an =
unfortunate Perl-ism, and I wouldn't mind renaming them at all.

> The way I see it, these type annotations *are* a DbC syntax. Why do =
you see it as otherwise?

I don't. Sorry, I guess I wasn't being clear. It's not that I don't like =
the idea of checking arguments for methods. It's that DbC is bigger than =
just that. My view on this is that we shouldn't just stop at method =
checks. I'd like to see Ruby gain the full suite of DbC capabilities.

> Weren't you just all about the duck-typing, and now you're calling =
them unreliable and difficult? :) In any case, I don't think that's very =
relevant.

Au contraire! I think this is the *most relevant part of the issue*. As =
I've said in a few other messages in this thread: I'm not against having =
type information or being warned about type conflicts. What I don't want =
is I don't want to have to type in the information by hand!

I think I do understand your proposal, but I think it's a lazy short-cut =
solution to a more fundamental problem. Could we have better tools, =
better warnings, and maybe some small performance improvements by =
allowing for optional type annotation? Sure! But its a hack. I would =
like to see Ruby solve this problem in a more fundamental way...

Cheers,

Josh=