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

Hi,

Thanks for all the feedback and questions. I'll respond to everything in =
one email, rather than respond to different people individually. It =
seems that there have been 2 general points:

1. Ruby is duck typed and changing that to accommodate static typing =
would go against Ruby's dynamic nature
2. What is it about explicit typing that allows for better tools.

First, it might be worth just separating my proposed solution from the =
actual problem. The problem is that there is no easy or reliable way to =
get return or argument types for a method, such information being useful =
in building smarter tools. The first point relates more to my specific =
proposal for a solution the second is more about why the problem is a =
problem.


So, for the first point. It seems I might have put too much emphasis on =
the wrong things, but what I was proposing was not to change the dynamic =
nature of Ruby in any way, but simply to add a syntax addition. =
Essentially this would work exactly like Objective-C, in that the type =
information for objects is there prior to runtime for any tools to use, =
but the type information is not there at runtime as objects are duck =
typed in Objective-C.

Now this isn't the only possible solution. I think the DSL suggested by =
Asher is another interesting solution, that would allow both tools and =
apps themselves at runtime to get this information. It does remove the =
need for adding anything to the language syntax and could be more =
flexible, but at the same time may require more work on the part of =
users. It's definitely a good alternative that I hadn't thought of so it =
would be interesting to explore it more.


As for the second point, I think the best way is to answer Asher's 3 =
questions:

1. What tools should exist?
Put simply IDEs. Some people don't like IDEs, some love them. But a good =
IDE will provide comprehensive autocomplete, powerful refactoring and =
possibly static analysis and error checking. These are all things that =
could be separate tools rather than built into an IDE. They could also =
be added to existing text editors.

2. Which of these tools don't yet exist or should exist with better =
implementations?
There is one example I know of an IDE that does do most of this stuff =
already: RubyMine. There are two issues though, one somewhat =
superficial, one not so superficial. The superficial one is that I'm a =
Mac user and I prefer that my tools don't feel like a straight port from =
Windows, so anything that would aid native tools is helpful. The not so =
superficial is that these tools are built almost entirely upon type =
inference.

3. What is the inherent relation of these tools to typing?
So what is the inherent relation with typing and these sorts of =
features/tools. Well I'll give two examples to demonstrate. The first is =
autocomplete. If we do not know the type of a variable then we're =
essentially doing a simple "begins with" search on every method known to =
the autocomplete system (all of ruby core + any extra libraries + the =
developer's app). Once we know the type, we can dramatically filter this =
list to just the relevant class.

The next example is refactoring. Now you probably wouldn't do this but =
say you wanted to rename the to_i method on String to to_integer (I'm =
assuming for a second these classes aren't done in C). Without type =
information, you might as well just do find and replace across the whole =
project, but the issue is that there are 9 other to_i methods on various =
other classes. If you know the types of variables, then you can replace =
the to_i on all those that are strings without touching any that aren't.

Now, you can use type inference here, as it would allow you to get a lot =
of the types without having to do anything special, but type inference =
is far from foolproof. The issue is that is it purely guessing based on =
what it has in front of it. All code has assumptions that are not fully =
coded into it and you cannot necessarily deduce these assumptions. A =
human may be able to, but writing some code that can get into the head =
of the person who initially wrote a method is somewhat hard ;)

Any tools would likely make use of type inference to get a large part of =
the way there, but the more stuff that is explicitly stated the less =
that has to be guessed or assumed, so the more useful type inference is =
when it is needed


Hopefully that answers the questions that were asked, sorry if it =
hasn't. There's no one solution to the problem. It could be that =
optional static typing is the best solution, or it could be that a DSL =
like Asher suggests is better, or there could be something that hasn't =
been suggested yet that be better still.

Thanks

Martin


On 28 Sep 2010, at 12:52PM, Asher wrote:

> Perhaps we would be better served by talking about what sorts of tools =
we desire. "Reliable" is obvious enough, but what of "powerful"? How are =
we to define this aspect of tools, particularly regarding Ruby =
specifically?=20
>=20
> So some questions:=20
>=20
> 1. What tools should exist?
>=20
> 2. Which of these tools don't yet exist or should exist with better =
implementations?
>=20
> 3. What is the inherent relation of these tools to typing?