[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.=20

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?=20

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

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

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

So some questions:=20

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).=20

Best,
Asher


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

> Hi Matz
>=20
> 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.
>=20
> 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.=20
>=20
> 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.
>=20
> 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.
>=20
> Thanks
>=20
> Martin
>=20
>=20
> On 27 Sep 2010, at 4:29PM, Yukihiro Matsumoto wrote:
>=20
>> Hi,
>>=20
>> 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:
>>=20
>> |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).=20
>>=20
>> Short response:
>>=20
>> "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
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 							matz.
>>=20
>=20
>=20