[ruby-talk:23097] Re: Bruce Eckel's opinion of Ruby

On Tuesday 23 October 2001 13:30, you wrote:
> Hi Eric and thanks for your detailed comments,
>
> I'm trying to understand them fully and have some questions. Would be
> great if you have the time to answer them.
>
> > 1. Python's namespace conventions (i.e., no "global" global variables,
> > only module-global variables) make it easier to partition a large project
> > amongst various programmers, especially projects that require
> > configuration variables of some sort (which are "global""), where you can
> > divide them amongst several programmers/several modules without worrying
> > about conflicts.
>
> Do you mean that if there is a (in some aspect) "bad" language construct
> it will be used? Or is there something that can be done in Python here
> that is not possible with Ruby (here: class vars in module)?

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. 

> > 7. Access to object namespace in Python allows very easy self-referential
> > classes.
>
> Hmm, sounds interesting. Can you show example or point me to one?

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. 

> > My preliminary conclusion is that Python is a superior language for large
> > projects. It is virtually impossible to make a difficult-to-read Python
> > program due to its indentation-based syntax,
>
> IMHO, Python is hard to read. And passing self along hides the essence...

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:
    if condition :
         clause
    else:
          clause
which eliminates fighting through if statements that look like this:
    if (something) { this(); } else { that(); }
all piled on top of each other. 

> > the namespace partitioning makes
> > large projects easier to partition amongst multiple programmers or
> > multiple programming groups,
>
> Could you give a concrete example of this?

Mostly lack of "true" global variables here. There is no common namespace for 
programmers to stomp around in. Thus variables end up getting either 
instantiated into an explicit module-specific namespace for their particular 
module, or end up migrating into a class. It's hard to provide an example of 
LACK of something :-}. 

> > and there is a large number of enterprise-oriented
> > libraries for access to various proprietary and non-proprietary external
> > systems.
>
> Ok.
>
> > It is also portable to more architectures than Ruby, which is
> > important for some large multi-platform applications.
>
> Ok.
>
> > Python's syntax is also
> > more regular and consistent than Ruby's, which again is important for
> > large multi-programmer projects.
>
> Why is it more important? To enforce a certain coding format? Example?

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 to 
cope with new changes to accounting rules) was an exercise in decrypting 
COBOL syntax written with "C" preprocessor macros. Tasks that should have 
taken me minutes took hours instead. The point is that a clear, regular 
syntax eases the task of future maintenance. Python has been criticized as 
having a rigid and inflexible syntax, and to a certain extent that is true. 
But for very large projects, that's a virtue. 

> > I
> > 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 the class 
heirarchy. Python does not have a class heirarchy, but has modules which 
handle some of the management issues. C++, prior to namespaces, could swiftly 
become unmanageable, and Ruby's management issues seem to me to be similar to 
those of C++. (Even with namespaces, C++ is not my favorite language... I 
prefer Java whenever possible if I have to use a compiled language but don't 
need the absolute performance of "C"). 

> opposite even though the difference to other languages might not be
> revolutionary. I use Ruby more as a general programming language than as a
> scripting language.
>
> NOTE: I'm not into any language flaming here; just trying to understand
> your points better.

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" here is that 
Ruby is an excellent scripting language but that I wouldn't want to write a 
large multi-programmer project with it. This, however, doesn't mean that YOU 
would have difficulty writing a large multi-programmer project with it (after 
all, some people have succeeded with *PERL*, of all things!), just that 
Python has more "goodness" for that for my style of project management than 
most other languages that I've encountered (for that matter, the much-derided 
Java also has a lot of "goodness" for multi-programmer projects, which is 
probably why IBM is pushing it everywhere). Quantifying "goodness" is a hard 
thing to do, and I'm not sure I can successfully do so. After all, if us 
experienced old hands could communicate everything we knew, there wouldn't be 
much use for us, right? :-). 

-- 
Eric Lee Green          GnuPG public key at http://badtux.org/eric/eric.gpg
           mailto:[e-mail]  Web: http://www.badtux.org
             You do not save freedom by destroying freedom