From: Sean Russell <ser@...>
Date: 2001-10-24T08:07:28+09:00
Subject: [ruby-talk:23119] Re: Bruce Eckel's opinion of Ruby

Eric Lee Green wrote:

> More like something that can be done with Ruby (true global variables)
> that cannot be done with Python. With Python, all "global" variables are
> module-specific. This is similar to class variables, except not (Ruby
> doesn't really have Python-style modules, what it has is, well,
> different).
> 
> Basically, what this means is that other programmers are less likely to
> somehow tromp on important global data.

Ummm... then don't use global data.  At worst, you'd be no worse off than 
if you had used Python.

> I can't show you example, but can describe one. In last large Python
> program that I wrote, we had a 'dbaccess' class. This class encapsulated a
> generic possible record type in the database. This class was subclassed by
> individual classes for each record type in the database. Each record type
> instantiated class variables in its declaration for table name, field
> names (list), and field types (list). The initializer for the dbaccess
> class stuffed the field names into the instance of the end class as
> variables. Thus if I have a "Customer" table, with field names "Last",
> "First", "Middle", "CustNum", I could do something like
> 
> l=Customer(5324)  # get customer #5324
> print "Name =",l.Last,",",l.First," ",l.Middle
> 
> 
> And if I wanted to change his name, I could say something like
> 
> l.Last="Ferguson" # she married
> l.Update()        # and change it on disk.
> 
> and voila. All this was handled automagically behind the scenes via
> self-referencing on the part of the base 'dbaccess' class.

I can think of several ways of doing this in Ruby.  The easiest would be 
the method_missing method:

class DBAccess
        # Define update(), etc
        # ...

        # Remember, they used this in the PickAxe book to generate
        # roman numerals
        def method_missing( *mname )
                # if the method name ends in "=", then this is a set
                if mname[0][-1] == ?=
                        row_values[mname[0].chop] = mname[1]
                # otherwise, get
                else
                        row_values[mname[0]]
                end
        end
end

You wouldn't even have to subclass the class to make this work.  It sounds 
more elegant and space efficient than the Python solution, but maybe I'm 
missing something.

> But you're not working on a large project with multiple programmers. A
> clear and *CONSISTENT* style is important in such cases. Whether you
> personally like that style or not is largely irrelevant. If the language
> largely enforces such a style, this makes the code in large projects much
> easier to read. I'll note that virtually every programmer eventually has
> to go into a module written by some other programmer and add new features
> and/or fix it. With Python, you guarantee that the coding style is
> reasonably consistent (e.g. every if statement looks like this:

There is a truth in what you say.  Where you are mistaken is in assuming 
that it is neccessary that the programming language to enforce this.  We 
(collectively, as a society) have been using C, C++, and Java in commercial 
environments for years, and coding standards are a common, and not 
difficult, way of solving this sort of problem, without the limitations 
imposed by a language-enforced coding style.

The main difference is that, with Python, Guido V.R. is determining how all 
of you are going to style your source.  I'd rather have local control over 
that sort of thing.

> Mostly lack of "true" global variables here. There is no common namespace
> for programmers to stomp around in. Thus variables end up getting either

I'm increasingly getting the feeling that there isn't much structure in 
your work environment.  Again, I'd rather have local control, than leave 
that sort of thing up to the language designer.  IMO, if things are that 
chaotic at your shop and you're trying to work on large, diverse projects, 
you're going to have bigger problems than just whether or not your source 
code is readable.

>> > It is also portable to more architectures than Ruby, which is
>> > important for some large multi-platform applications.

I'd say this is more of a momentum thing.  Give it another year or two, and 
the gap will be so small you won't notice it.  Granted, that doesn't help 
you /now/...

> Uhm, and you've worked on how many large multi-programmer projects? I once
> worked on a project that had over 1,000,000 lines of code that had been
> written by a dozen programmers over a 10 year period. One programmer in
> particular irritated me to no end -- he did everything as if he were
> programming in COBOL. Fixing his programs (or, more usually, updating them

Hmmm.  Well, given that there is no such thing as a 10 year-old Python 
project, proving that Python is superior in this case would be rather 
difficult.  Bad code is bad code.  That said, I'll agree that any given 
Python source has a better chance of being legible to other Python 
programmers that Ruby.

>> > would not, however, relish attempting to manage 100K+ lines of Ruby
>> > code for a project, while Python proved to be quite usable for 100K+
>> > lines of code.
>>
>> I don't agree with this but I haven't developed any 100K+ lines of Ruby
>> programs. Why will Ruby "break down"? My feeling has been quite the
> 
> Note that I have not developed very large programs in Ruby either, I'm to
> a certain extent comparing it to what I've seen happen in very large
> Python, C++ or Java programs. Large Java programs are managable because of

Just out of curiosity, what is the largest *Python* codebase (for a single 
application) that you've worked with?

> I'm not sure that I understand all my points myself :-). Some of this is
> just gut feel from close to 20 years of programming in everything from
> DBASE-II (how debased!) and PL/1 to Python, Java, and Ruby. My "gut feel"

OMG!  Another DBASE-II veteran!

--- SER