[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? 
> 
> So some questions: 
> 
> 1. What tools should exist?
> 
> 2. Which of these tools don't yet exist or should exist with better implementations?
> 
> 3. What is the inherent relation of these tools to typing?