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

Martin,

With respect, I think you're considering this backwards, attempting to adjust Ruby in order to address how you're used to dealing with language. 

As I see it, one of the major advantages of Ruby is its flexibility, insofar as it figures out for you many details (such as implicit typing). One of the major disadvantages of Ruby is that it has to figure out all of these details. In other words, attempting to satisfy both the advantages and disadvantages of typing in this way is likely to do little other than amplify the disadvantages of Ruby (primarily the underlying weight of the VM) as well as the disadvantages of typing (having to specify details everywhere, having to update details in multiple places for minor changes, etc.)

So you say "reliable, powerful tools" - why does this correspond to typing in any way? 

I think instead we should be asking what "powerful" and "reliable" mean in a programming context where typing is not the primary emphasis. What is a hardened Ruby program? I think this is worth asking, but I don't think it's a question whose answer is barred by way of any relation to typing. 

Some languages (PHP?) have dealt with this by using "type hints", but I think this simply encourages the wrong approach, emphasizing explicit typing over patterns that are not type-reliant. For instance (as many web pages/blogs will attest), a common pattern for Ruby-newbies is first Class checking, and second method response checking. While there are (rare) appropriate applications for these tests, most of the time they are misplaced and are symptoms of a view of language that comes from somewhere other than Ruby. 

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?

I think that much of what we are dealing with here is what I would call a distinction between meta-programming languages and memory-programming languages. Ruby is not a memory-oriented programming language, but a meta- oriented programming language. The functionality of Ruby has far more to do with contingent context elaborated at a run-point in the program context than it does with the mapping of code structures to computer (memory) structures. In other words, the brilliance of Ruby is that the code is not about how the computer works, but is about how the objects work (which require no inherent relation to the computer itself or to their particular mode of storage in memory). This seems to me to deal first and foremost with "getting away" from types while nevertheless retaining the underlying benefits that types provide (albeit mostly invisibly). 

Best,
Asher


On Sep 28, 2010, at 6:53 AM, Martin Pilkington wrote:

> Hi Matz
> 
> Thanks for the reply. I full agree with you (and Alan Kay) that typing can be a pain, though due to benefits in more accurate and effective tools there are advantages to it. If there was a way to easily and reliably get tools as powerful as languages with static typing without the need for the typing then I'd be all for it as I love using duck typed languages and the freedom they give.
> 
> I did consider structural typing and it could be a route to go down. Ultimately I'm just wanting a better way for me and others to build reliable, powerful tools for Ruby, regardless of how that is approached. I did hit a snag when considering structural typing though, which may be due to my relative inexperience with structural typing, so you might be able to help with a solution. 
> 
> Obviously structural typing is great at easily working out whether two objects are technically interchangeable, whether or not they conceptually are. However, while you can say that a String object is simply one that has methods +, <<, concat, length, split, sub etc, it's somewhat harder to say what the argument and return types of those methods are (of course that is a somewhat bad example given that the return values/types are given for the very base classes and their methods, but you get the idea). This is ultimately the main reason for me wanting some degree of pre-runtime typing (the return types more than the arguments) and I can't see any way to calculate these types without type inference, which itself I see snags with.
> 
> I'm just wondering if you have any thoughts about getting this method type information? I could just be overlooking something that a fresh (and far more experienced with Ruby) pair of eyes can see, but I'm just struggling a bit with reliable ways to get the type info needed.
> 
> Thanks
> 
> Martin
> 
> 
> On 27 Sep 2010, at 4:29PM, Yukihiro Matsumoto wrote:
> 
>> Hi,
>> 
>> In message "Re: [ruby-core:32585] Proposal for Optional Static Typing for Ruby"
>>   on Mon, 27 Sep 2010 20:58:51 +0900, Martin Pilkington <[e-mail]> writes:
>> 
>> |I know this is my first post on this list and that I'm relatively new to the Ruby community, and that this can be a somewhat controversial topic (as I've found by asking about it on the #ruby-lang channel). 
>> 
>> Short response:
>> 
>> "I'm not against types, but I don't know of any type systems that
>> aren't a complete pain, so I still like dynamic typing." - Alan Kay
>> 
>> Static typing surely has its benefit, but on the other hand, Ruby the
>> language strongly encourages duck typing, so that its type system
>> should not hinder duck typing.  As a result, the type checking should
>> be based on structural types, not nominal types.  I don't think your
>> proposal cares about duck typing or considered structural type
>> conformance.
>> 
>> Although I like your <type> notation, that reminds me the scheme
>> object system, iff we don't have to write them often.  I don't think I
>> could stand to write <type> everywhere.
>> 
>> 							matz.
>> 
> 
>