From: Martin Pilkington <pilky@...>
Date: 2010-10-01T00:21:47+09:00
Subject: [ruby-core:32656] Re: Proposal for Optional Static Typing for Ruby


--Apple-Mail-20-462716889
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Ellie,

I think you're misunderstanding the power of Objective-C. It is =
essentially C + Smalltalk. It is heavily runtime based and various =
patterns rely upon proxy objects that forward or intercept messages, on =
querying objects for method implementations at runtime, on the ability =
to dynamically add methods at runtime or to exchange the implementations =
of two methods. You can't do something like module_eval with a string as =
it is a compiled and not interpreted language (theoretically it could be =
possible but isn't today) but you could add a new method by using a =
block as the implementation (not part of an official API but with a few =
methods it is possible).

I'm fully aware of the power of dynamic languages, as with Objective-C I =
use one every day. After all, it's no fluke that Ruby has been able to =
be re-implemented on top of the Objective-C runtime in the form of =
MacRuby. However, I'm also aware of the benefit of having type =
information without having to execute the full code.

Thanks

Martin


On 30 Sep 2010, at 3:36PM, Eleanor McHugh wrote:

> Hi Martin,
>=20
> When we say that Ruby is a dynamic language we're not just referring =
to the fact it supports dynamic typing, but also tacitly saying that the =
code encountered at runtime is only loosely coupled to that which is =
embodied in the source code. As a community we probably don't discuss =
this as often as we should, especially given that many of the more =
powerful code refactoring tricks in our toolkit rely upon the use of =
module_eval to customise objects or mess with the class or meta-class =
hierarchy. In this sense our mindset is much closer to that of Lisp =
(eval) or Forth (create...does) than it is to any of the C family of =
languages.
>=20
> So whilst I agree that for the particular instances you discuss code =
annotations could indeed be helpful upon occasion, I'm much more =
sceptical of their general application and hence of the desirability of =
adding another layer of complexity to Ruby's interpretation model - =
especially if that additional layer of complexity doesn't result in any =
direct runtime benefit.
>=20
>=20
> Ellie
>=20
> Eleanor McHugh
> Games With Brains
> http://feyeleanor.tel
> ----
> raise ArgumentError unless @reality.responds_to? :reason


--Apple-Mail-20-462716889
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi =
Ellie,<div><br></div><div>I think you're misunderstanding the power of =
Objective-C. It is essentially C + Smalltalk. It is heavily runtime =
based and various patterns rely upon proxy objects that forward or =
intercept messages, on querying objects for method implementations at =
runtime, on the ability to dynamically add methods at runtime or to =
exchange the implementations of two methods. You can't do something like =
module_eval with a string as it is a compiled and not interpreted =
language (theoretically it could be possible but isn't today) but you =
could add a new method by using a block as the implementation (not part =
of an official API but with a few methods it is =
possible).</div><div><br></div><div>I'm fully aware of the power of =
dynamic languages, as with Objective-C I use one every day. After all, =
it's no fluke that Ruby has been able to be re-implemented on top of the =
Objective-C runtime in the form of MacRuby. However, I'm also aware of =
the benefit of having type information without having to execute the =
full =
code.</div><div><br></div><div>Thanks</div><div><br></div><div>Martin</div=
><div><br></div><div><br><div><div>On 30 Sep 2010, at 3:36PM, Eleanor =
McHugh wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: =
normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Hi =
Martin,<br><br>When we say that Ruby is a dynamic language we're not =
just referring to the fact it supports dynamic typing, but also tacitly =
saying that the code encountered at runtime is only loosely coupled to =
that which is embodied in the source code. As a community we probably =
don't discuss this as often as we should, especially given that many of =
the more powerful code refactoring tricks in our toolkit rely upon the =
use of module_eval to customise objects or mess with the class or =
meta-class hierarchy. In this sense our mindset is much closer to that =
of Lisp (eval) or Forth (create...does) than it is to any of the C =
family of languages.<br><br>So whilst I agree that for the particular =
instances you discuss code annotations could indeed be helpful upon =
occasion, I'm much more sceptical of their general application and hence =
of the desirability of adding another layer of complexity to Ruby's =
interpretation model - especially if that additional layer of complexity =
doesn't result in any direct runtime =
benefit.<br><br><br>Ellie<br><br>Eleanor McHugh<br>Games With =
Brains<br><a =
href=3D"http://feyeleanor.tel/">http://feyeleanor.tel</a><br>----<br>raise=
 ArgumentError unless @reality.responds_to? =
:reason<br></span></blockquote></div><br></div></body></html>=

--Apple-Mail-20-462716889--