[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