From: Alan Chen <alan@...>
Date: 2001-10-24T08:41:21+09:00
Subject: [ruby-talk:23123] Re: Bruce Eckel's opinion of Ruby

On Wed, Oct 24, 2001 at 06:00:48AM +0900, Paul Brannan wrote:
> On Wed, 24 Oct 2001, Michael Neumann wrote:
> 
> > Use the block paradigm instead. E.g.
> >
> > DBI.connect do | dbh |
> >   # do something with dbh
> > end
> >
> > or
> 
> This works fine for short-lived objects, but how can I use blocks for
> objects that get passed around?  I think that would be a case where I
> would have to implement my own reference counting in Ruby.  Not a common
> case, imo, but still important to consider.

You mean like this?

class SaveABlock
  def initialize(&block); @block = block; end
  def useablock; @block.call 1; end
end

a = SaveABlock.new { |i| puts "i: #{i}" }

a.useablock  => i: 1

> >
> > I'd hold against your last sentence, but I never tried it out.
> > But maybe 100K lines in Python are just 50K in Ruby ;-)
> 
> The problem is not the number of lines itself, but that projects that
> large have certain needs, and Ruby makes it difficult to meet those needs.
> For example, using inheritance in Ruby on a team with many programmers may
> be difficult, because really is no such thing as private instance data in
> Ruby. Nifty funtions like send() and method() allow the user to call
> private/protected methods that they should not be allowed to call (at
> least, not by accident).  Ruby lets you define a public method in a
> derived class that was private in the base class without so much as a
> warning, so you need to have full knowledge of the base class's *private*
> interface if you don't want to break something.

My impression is that you may be mistaking lack of maturity in Ruby
for lack of "large scale development" features.  The developer
methodologies to cleanly interface modules in large scale projects
haven't had as much time to mature in Ruby as in Python.  I think its
premature to make assesments of Ruby's suitablility for large-scale
programming. Many of the "large-scale" features mentioned previously
on this thread are really nice-to-have items not have-to-have.

All large scale development languages allow access to private data,
its a matter of how much pain you want to put the developer through if
they elect to access a non-public interface.  FWIW, I suspect that it
would be easy to write a module to disable the send and method
functions in a class. (or provide a warning if you'd prefer)

For me ruby as a language shows exceptional clarity and elegance at
many different levels. For example, I think the ease of interfacing
ruby with C will result in the language aquiring library bindings much
faster than Python or Perl in their early stages of maturity.  Ruby's
tradeoff between design purity and expedience is pretty much perfect
for me.

-- 
Alan Chen
President and Lead Developer
Digikata LLC
alan@digikata.com
http://digikata.com