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

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 didn't got your point, but I am sure this can be done very easy
in Ruby.
In Ruby you can create on-the-fly new classes, add methods, pass classes
around (classes are objects) etc... 

> > 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. 

You will rarely see such constructs in block-languages like Modula, Ada
or Ruby.
In Ruby you could write:

  if something then this else that end

Instead I'd write this using the ? operator:

  something ? this : that

But usually you'd write:

  if something [then]
    this
  else
    that
  end

But this problem you have in almost any other language, too, be it 
Java, C/C++ or Eiffel. And in those languages far more larger and more critical 
application were written than there will ever be in Python.

I think this is just a matter of disciplin, or the right tools you use.

> > > 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 :-}. 

global variables will be depreciated in Ruby 2.0 ;-)
no, of course not.

> > > 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 think, this too is a matter of discipline.



Regards,

  Michael

-- 
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de