From: Eric Lee Green Date: 2001-10-24T06:20:52+09:00 Subject: [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:eric@badtux.org Web: http://www.badtux.org You do not save freedom by destroying freedom