From: Bill Kelly <billk@...>
Date: 2001-10-24T16:58:45+09:00
Subject: [ruby-talk:23151] Re: Bruce Eckel's opinion of Ruby


From: "Eric Lee Green" <eric@badtux.org>
>
[...]
> 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. 

self.I've self.worked self.on self.more self.Python self.programs
self.than self.Ruby self.__ahem__.__er__.__pardon__.__me__ than
Ruby programs at this point.

And I agree that the lack of "namespaces" and global consequences
for extending/changing the behavior of some class in Ruby seem
daunting, especially for a non-pair-programmed non-test-first-
designed non-collective-code-ownership based project written by
a bunch of unrepentant ex-COBOL programmers working in separate
offices and communicating via the occasional email.

Hahah haah haha ahhaa hah ha yeah, I've on a couple occasions
had to fix bugs in and extend code like that too.  :-)

But I refuse to let programmers like that influence my choice
in languages (maybe I'm just stubborn.)  So, which language
might you consider for large projects if you knew everybody
involved was writing good code and was actually willing to
_learn_ the language?  I know the Smalltalk folk have somehow
learned to manage cascading effects or clashes from extending
functionality in base classes (though from what I've read 
they've learned to be careful/cautious about doing so, too?)
But the Smalltalk existence proof makes me less nervous about
Ruby's capabilities somehow [on a large project] - at least
with the stipulated good-programmers-working-on-it clause from
above in effect.

. . . I guess my point is, in thinking about it and trying to
figure it out myself :), is that it seems you've made a case
yourself for the language having little effect on someone 
who is deliberately (or ignorantly) out to abuse it.  At least,
for me, if I were to translate the bad 'C' code I've been
subjected to into Python, it wouldn't really help a bit!  
Because I have/had no trouble 'tall parsing the 'C' language
statements these people were writing (had written).  It's
just the larger context was one big horrific mess: what the
program was doing and how it was doing it.

Hmm, I was going to say, "... so it (the bad code) may as 
well be in Ruby, or even Perl...", but, I've more Perl 
experience than either Python or Ruby, and I'm not sure I'm
brave enough to make *that* assertion.  ;-)   Okay, so maybe
the 'abusability' of the syntax does matter somewhat where
bad-ol'-programmers are concerned (or bad new programmers -
not targeting age here;) . . . uh . . . still, with the
good-programmers-on-the-project deal stipulated above, I
don't think I can fathom any reason for choosing Python
*just* because of it's syntax.  

Okay, . . . hope this made some sense, anyway.  :)


Bill