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

  Hi Joshua,

On 9/29/2010 2:26 PM, Joshua Ballanco wrote:
> 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.
>
I'm not a fan of blanket statements like these. Neither am I a fan of 
that kind of a conclusion. The Ruby solution is not always "remove class 
coupling". Again, I should bring around the point that Ruby is 
multi-paradigm, and has class based support for a good reason. If you 
want Ruby minus the classes, maybe LISP is a better language for you. 
For the rest of us, classes will be a mainstay in the way things are 
done. In any case, your opinion on classes or duck-typing doesn't really 
have much effect on the actual proposal, since annotated types could 
support (and would be useful for) either one.

> 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 problem here is that you can't rename methods like #[], or 
operators. #slice is also known as #[] (as I pointed out), and must 
therefore work as "str"[...]. And commonly overloaded operators like +, 
===, and especially <=> would also benefit from this syntax. In any 
case, I don't believe the Obj-C way of doing things is the right way 
here. I wouldn't want to have "xyz".slice_with_range(). As we discussed 
earlier, the advantage of using Ruby and duck-typing is that you can 
have simple APIs that "Just Work". For instance, if I wanted to slice a 
String sometimes at a Fixnum but other times at Range, I would need to 
think about what I was calling and have an if statement that chose 
between two methods.

     if range_end?
       str.slice_with_range(start...finish)
     else
       str.slice_with_fixnum(start)
     end

Having a single verb #slice simplifies this:

     str.slice(range_end? ? start...finish : start)

Naming things verbosely doesn't really solve the overloading problem, it 
only solves the documentation problem (and only partly).

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

You want full DbC capabilities but don't encourage adding type 
information? A "full" DbC implementation includes static checking, and 
that can *only* happen with type information. Without types the best you 
can do is Runtime Assertion Checking (RAC). Frankly, Ruby will never get 
to static DbC verification, because it will never have static types, 
however you can get a lot closer by annotating when the compiler needs 
more information.

More specifically, I pose you this question: how do you expect to have 
"full" DbC capabilities, or even partial ones, without type information? 
You can merge this answer with the next quote, since I have a feeling 
they're related.

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

You want type information but don't want to add it? Where will the type 
information come from if not "by hand"? The compiler can only go so far 
in terms of type inference. Specifically, inferring types of parameters 
is nearly impossible, and any form of metaprogramming would completely 
throw the compiler into a loop. The only way to fill in these gaps is to 
add these types in as annotations.
> 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...

Where's the hack, or rather, what's the fundamental problem, then? If 
the fundamental problem is "people shouldn't need the tools or warnings 
in the first place", I'm not buying that. It seems to me as though 
you're stance on this matter is far more ideological and far less 
practical than it should be. I certainly appreciate that, but this is 
not an ideological issue-- I mean, the typing would be *optional*. If 
you wouldn't see a benefit from this, you can certainly opt-out. On the 
other hand, I see no problem with getting better tools, better warnings 
and small performance improvements by allowing optional type 
annotations. I'll bet the majority of users solving practical problems 
would agree. In fact, I find it extremely hard to argue against "better" 
anything if the cost only involves adding an optional syntax.

- Loren