From: Jos Backus <jos@...>
Date: 2007-01-22T05:39:40+09:00
Subject: Re: Scoping and locating definitions

    Hi Wayne,

On Mon, Jan 22, 2007 at 03:57:59AM +0900, Wayne Vucenic wrote:
> Hi Terry,
> 
> On 1/20/07, Terry Weissman <terry@liveops.com> wrote:
> >The point is, in Python, if file A chooses to import package B, it is
> >very unlikely to affect code operating in completely unrelated file
> >C.  In Ruby, it's entirely possible that the import of B could have
> >broken something that C depended on.

A typical example (correct me if I'm wrong) would be for somebody to override
an existing method, introducing differing behavior whereas you'd be relying on
the behavior of the original method. E.g.:

    lizzy:/tmp% cat x
    class Foo
      def bar
	puts "hi"
      end
    end

    class Foo
      def bar
	puts "ho"
      end
    end

    Foo.new.bar
    lizzy:/tmp% ruby x
    ho
    lizzy:/tmp% 

In Ruby's defense, there's:

    lizzy:/tmp% ruby -w x
    x:8: warning: method redefined; discarding old bar
    ho
    lizzy:/tmp%

To make this more useful, one of my proposals is to augment this information
such that the interpreter would be able to tell you where it found the old
definition:

    lizzy:/tmp% ruby -w x
    x:8: warning: method redefined; discarding old bar at x:2
    ho
    lizzy:/tmp%

This would be helpful when trying to figure out where methods are defined.

Similarly:

    lizzy:/tmp% cat x    
    FOO = 1
    FOO = 2
    lizzy:/tmp% ruby x   
    x:2: warning: already initialized constant FOO at x:1
    lizzy:/tmp% 

> As you pointed out, this is a trade off between having a powerful
> language and having a safe one.  Most languages that I know won't let
> me redefine the + operator for integers.  I really like that Ruby lets
> me do it.  (I haven't needed to redefine +, at least not yet.)
> 
> I can imagine a reasonable language that has the features you'd like.
> I just wouldn't call it Ruby.
> 
> I'm glad Matz chose to position Ruby much more towards the "powerful"
> end of the spectrum rather than the "safe" end.  There are domains
> that can benefit from a lot of safety, and others that can benefit
> from a lot of power.  If I were programming the control system for a
> nuclear reactor, Ruby probably wouldn't be my first choice.  But
> that's one reason I don't do those kinds of projects.
> 
> >If you are in a world where all the code is written by good,
> >competent programmers who've agreed on the ground rules, Ruby can
> >give them all a lot of power.  But if you're not so sure about your
> >fellow programmers, or about code that you are loading off the net,
> >then Ruby's model offers much less protection than Python's.
> >
> >This kind of thing would make me much more scared to work on a big
> >project in Ruby than I would be in Python.
> 
> I wouldn't want to program a large project in Ruby with programmers
> that I didn't trust.  But having been on projects like this using
> "safer" languages, I also wouldn't want to program a large project in
> _any_ language with programmers that I didn't trust.  There are just
> so many ways another programmer can make a project difficult, and any
> language can only protect you from a handful of them.
> 

True. But I still wonder if some compromise wouldn't be possible through the
use of scoping control.

> (Hi Jos!  How are you doing?)
 
Doing fine :-) *waves*

> Wayne
> 
> ---
> Wayne Vucenic
> No Bugs Software
> Ruby, C#, and Erlang Agile Contract Programming in Silicon Valley
> 

-- 
Jos Backus
jos at catnook.com