Declaration of object attributes/methods determine public accessors for such variables in Ruby, while in Python you may create an object attribute on the fly, like in a mistyped variable. Let me try it:

I prefer Ruby's version. It seems more explicit and clearer and a nicer convention overall. How is that for a language that does not have the slogan of being as explicit about things as Python does? Can you imagine thousands of lines of Python where if you mistype a variable like that you may cause some bug? Also, note that Python could break backwards compatibility and fix it, but is that desirable? Even if you have a way to trigger some warning, it's still a matter of not being explicit in the declaration of the attribute that's the problem.

and the question is about> > long> > > term projects and the whether or not stability can be> > > achieved with non-static objects. > > This is a question you have? Seriously? There are a LOT> of long term large scale systems written in dynamic

But Smalltalk is a entirely different language. [And as an aside, so many folks like Bruce Tate do not understand, Java is actually very close to Objective-C and Smalltalk (and *not* C++.] Surely we can find some large Ruby apps, given it has been around quite some time?

> > These are not small systems. This entire thread is fear> mongering from the C++/Java bigots.> And whining from Ruby zealots ;)

(And it's quite amusing to see the Python vs. Ruby slams also)

Anyway, it's a good question. So far I haven't seen a good answer. Along with good coders, good frameworks might help, facilitating good coding practices. But then see the point below.

Now, here's another question along similar lines, which speaks to the philosophy behind a language like Ruby, which again I think is a legitimate subject for discussion, no need for flame wars.

We've all been impressed by the Rails framework, the killer app for Ruby. But in this blog, the author "rails" against the users, telling them to stop using instance variables they didn't create, which, seems to me to support the argument the original poster is making:

Now, to play devil's advocate, is this simply Beta version 1.0 blues, where we never expected Rails would hit the trails as it did, and thus would've coded it much more differently? Or is this a design flaw in the language itself, which makes designing APIs and frameworks very difficult?

"Now, to play devil's advocate, is this simply Beta version 1.0 blues, where we never expected Rails would hit the trails as it did, and thus would've coded it much more differently?"

Or is it a known issue, and whatever language/framework/library might have their own issues as well?

"Or is this a design flaw in the language itself, which makes designing APIs and frameworks very difficult?"

I don't think so, having designed some of my own. Now if the question is changed to "which makes designing APIs and frameworks very __easy__?"

That may be a problem, though evolution has taken care of the unpopular things for you so you are guaranteed to use the "best" evolved approach, by whatever metrics the __environment__ chooses. :-) Aren't popular things super evolved or what? :-)