From: Robert Feldt <feldt@...>
Date: 2001-10-24T07:06:36+09:00
Subject: [ruby-talk:23104] Re: Bruce Eckel's opinion of Ruby

On Wed, 24 Oct 2001, Eric Lee Green wrote:

> > > 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. 
> 
I fail to see why this cannot be done easily in Ruby. But I probably don't
understand it ;-)

> > > 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. 
>
I agree with all of this. But coding standard and layout issues can be
handled outside of the language itself. Normalize and check style
conformance at check-in.

If one language had a more flexible syntax but allowed me to more clearly
express my intentions with the design and implementation one might
consider finding a way to restrict the syntax rather than dump the
language. I'm not saying that Ruby is more semantically powerful than
Python though (they're both Turing complete... ;-)).

> > 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 
>
Some but not many. Only C and VB though.

> 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 agree that clearness is key here. But syntax can be checked and
transformed. Maybe as part of the unit tests so you'd fail the
non-functional requirements of the coding standard? But ok, there
will be pedagogical issues in a language were there is more
freedom (In Python folks are used to one syntax so no reason to
discuss; may not be the case for Ruby).

Thanks for your interesting points.

Cheers,

Robert