Let me preface this post by saying that I'm no Ruby expert. I like it. It's fun. But I won't claim extensive knowledge on it.
So when this guy blogs about a Python quality that he feel is better than a Ruby quality:
It's the second generation that's going to be less enthused, that's going to stare in bafflement at these classes that mysteriously spawn methods, and trying to figure out what's going when there's an exception in dynamically generated code. You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it "monkeypatching". In Ruby they call it "opening a class" and think it's a cool feature. I will assert: we are right, they are wrong.
In message "Re: Diff of opinion on dynamic stuff" on Fri, 23 Dec 2005 06:27:50 +0900, "Drew Mills" <drewmi...@gmail.com> writes:
| In Ruby they call it "opening a class" and think it's a cool | feature. I will assert: we are right, they are wrong. | | -- http://blog.ianbicking.org/theres-so-much-more-than-rails.html | |I am curious what this means. Is Python against dynamic stuff? And |Ruby for it? And so we just agree to disagree? Or do I misunderstand?
"open class" is so strong (often too strong), we can break things easily. In other word, Ruby trust you to give you sharp knives, where Python don't. From the Python point of view, it's wrong, I guess.
> Let me preface this post by saying that I'm no Ruby expert. I like it. > It's fun. But I won't claim extensive knowledge on it.
> So when this guy blogs about a Python quality that he feel is better > than a Ruby quality:
> It's the second generation that's going to be less enthused, > that's going to stare in bafflement at these classes that > mysteriously spawn methods, and trying to figure out what's > going when there's an exception in dynamically generated > code. You can monkeypatch code in Python pretty easily, but we > look down on it enough that we call it "monkeypatching". In > Ruby they call it "opening a class" and think it's a cool > feature. I will assert: we are right, they are wrong.
> I am curious what this means. Is Python against dynamic stuff? And > Ruby for it? And so we just agree to disagree? Or do I misunderstand?
I think what he is complaining about are some of the dynamically created convenience methods provided by ActiveRecord when dealing with the Model for a database. Things like Person.find_by_user_name are methods which are implemented using method_missing to do specific searches of database tables. Because these aren't "real methods", Ian feels they could be hard to debug. He probably has a point. But in this case I think the convenience overrides the occasional weird bug. I don't keep up with the Rails list and haven't done much Rails programming yet, but it might be interesting to see how many problems there are related to these kind of methods. I suspect in reality there are many less than what Mr. Bicking might think.
Also his lack of Ruby knowledge is showing in that he is talking about method_missing implementations being like "opening a class", which they aren't. They are basically dynamic method dispatch.
There are a lot of neat things that can be done with method_missing that are very powerful and convenient. I certainly do not subscribe the Pythonic "it is better not to have something powerful if it can be occasionally dangerous" philosophy that Mr. Bicking is describing. I suspect most other Rubyists (and Matz) have the same opinion.
Regarding the issue of "re-opening a class", there is certainly room for abuse here. Again in my opinion the convenience and flexibility this provides probably out-weigh the risks. Others may not agree. But there are a lot of major Ruby libraries that would be totally different and/or impossible if we didn't have this feature. Rails and RubyGems both come to mind, as well as a lot of the code provided in the standard library. All I know is that I really cringe when I look back at Java code which requires separate utility classes for special String methods instead of just adding them to the String class (which you cannot do in Java without the source code for it.) To me it makes sense to just re-open the class and add the methods there, where they belong. But I've been programming Ruby for quite a while, so maybe I'm just brainwashed ;)
> Let me preface this post by saying that I'm no Ruby expert. I like > it. > It's fun. But I won't claim extensive knowledge on it.
> So when this guy blogs about a Python quality that he feel is better > than a Ruby quality:
> It's the second generation that's going to be less enthused, > that's going to stare in bafflement at these classes that > mysteriously spawn methods, and trying to figure out what's > going when there's an exception in dynamically generated > code. You can monkeypatch code in Python pretty easily, but we > look down on it enough that we call it "monkeypatching". In > Ruby they call it "opening a class" and think it's a cool > feature. I will assert: we are right, they are wrong.
> I am curious what this means. Is Python against dynamic stuff? And > Ruby for it? And so we just agree to disagree? Or do I > misunderstand?
Well, Python is plenty dynamic. I think he is complaining about Ruby's ability to re-open a class. This can make it difficult to find the complete definition of a class (imagine doing this in a completely random way in multiple files). So while it can be abused, it can also be an incredible simplification of the code you write. One thing it does is flattens inheritance hierarchies, you don't need to introduce specialising classes just to add a few methods. Using xampl as an illustration: the Ruby version of xampl generates 1 class for every 3 generated by the Java version of xampl, one of those classes is eliminated because I can re-open classes (the other is eliminated due to duck typing). Another thing reopening classes does is, obviously, to allow you to extend the built in Ruby classes (they are just classes after all). I suppose Ian would think things even worse because in Ruby you can do this to objects as well as classes.
This 'monkeypatching' is very similar to concepts in Smalltalk and CLOS (Common Lisp's object system). Nobody in those communities complains too much (though Smalltalk's browser reassembles classes for you, and new CLOS programmers are sometimes at a bit of a loss because in CLOS methods may belong to two or more classes and it doesn't seem that the obvious thing to do is the right thing). Ruby just makes thing a lot easier.
Yukihiro Matsumoto wrote: > "open class" is so strong (often too strong), we can break things > easily. In other word, Ruby trust you to give you sharp knives, where > Python don't. From the Python point of view, it's wrong, I guess.
Matz has put us in great danger. But Rubyist are okay with it I guess. I am strangely at peace with this perilous language in my home!
Superman does dangerous things to solve problems, too. He'll bend a street pole around a villianous guy. People, stop cheering.
Yukihiro Matsumoto wrote: > "open class" is so strong (often too strong), we can break things > easily. In other word, Ruby trust you to give you sharp knives, where > Python don't. From the Python point of view, it's wrong, I guess.
A chef will tell you that sharp knives are safer than dull ones, since they do not have to be forced.
-- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
On 12/22/05, Joel VanderWerf <vj...@path.berkeley.edu> wrote:
> Yukihiro Matsumoto wrote: > > "open class" is so strong (often too strong), we can break things > > easily. In other word, Ruby trust you to give you sharp knives, where > > Python don't. From the Python point of view, it's wrong, I guess.
> A chef will tell you that sharp knives are safer than dull ones, since > they do not have to be forced.
If these two quotes together aren't a perfect Ruby quotable quote, I don't know what is.
<tongue_in_cheek>
And now we have another weapon in the Python vs Ruby war:
Python: Dull Ruby: Sharp
</tongue_in_cheek>
Seriously though, a Python vs Ruby war is kind of dumb, since it is like brothers fighting.
why the lucky stiff <ruby-t...@whytheluckystiff.net> writes:
> Yukihiro Matsumoto wrote: >> "open class" is so strong (often too strong), we can break things >> easily. In other word, Ruby trust you to give you sharp knives, where >> Python don't. From the Python point of view, it's wrong, I guess.
> Matz has put us in great danger. But Rubyist are okay with it I > guess. I am strangely at peace with this perilous language in my > home!
> Superman does dangerous things to solve problems, too. He'll bend a > street pole around a villianous guy. People, stop cheering.
> _why
I'm going to play devil's advocate and hopefully somebody with some direct experience will chime in.
Rubyists are mostly people who know how not to aim at their foot, and are skilled in first-aid just in case. But what happens when the code is delivered and moves into maintenance mode? It falls into the hands of code-slaves who are just dying to sacrifice toes and heap the blame straight on you is what. I'm assuming it's these -- probably not Rubyist -- people who are being refered to as the "second generation".
Surely, if you delivered Pascal code instead of Ruby code, it would be less likely that the bozo trying to make a one-line change is going to end up deleting 25 million rows from your customer's database or something.
>> Is Python against dynamic stuff? And Ruby for it?
Certainly Python can't be against all dynamic stuff. Ain't that dynamic stuff what Eckel and others *like* about Python compared to Java -- 'latent typing', etc.? And can't you make the same sort of arguments against duck/latent typing that the blogger makes against open classes and dynamically generated code? For example:
"It's the second generation that's going to be less enthused, that's going to stare in bafflement at these methods that mysteriously accept any type, and trying to figure out what's going on when there's an exception in dynamically typed code."
Or you could even complain about operator overloading, which isn't even a dynamic feature:
"It's the second generation that's going to be less enthused, that's going to stare in bafflement at these operators that can mysteriously be overridden to do anything, and trying to figure out what's going when there's an exception in an overridden '+' operator."
Of course, he could still be correct -- maybe duck typing and operator loading are safe enough, and open classes are too dangerous. But it's still kind of interesting that a Python guy is criticizing Ruby for being *too* dynamic, flexible and open. That's of course the argument of the static typing crowd against dynamic typing. I guess he must hate class-less languages like Self (or even Javascript).
Maybe that's the core difference between the Python and Ruby philosophies? Ruby is even more dynamic and 'open'?
Ruby isn't Self, but seems closer to the idea that essence of OO is that objects respond to messages. Precisely how you create an object, whether via a closed class, an open class, a Javascript constructor, or whatever is less essential from that point of view. Whereas other languages seem to be much more class-centric.
I worked my way through a Python book a few years ago, but I've forgotten most of it. Are classes objects in Python?
On Fri, Dec 23, 2005 at 07:36:48AM +0900, why the lucky stiff wrote:
> Yukihiro Matsumoto wrote: > >"open class" is so strong (often too strong), we can break things > >easily. In other word, Ruby trust you to give you sharp knives, where > >Python don't. From the Python point of view, it's wrong, I guess.
I understood that 100%, and agree with it similarly. Keep in mind, I'm mostly coming to Ruby from the direction of Perl -- the Swiss Army Chainsaw to some -- and have no problem with being handed a sharp tool and being told to be careful with it.
Perhaps more imporantly than how this relates to my agreement, though, is the fact that I think you have hit on a fundamental point of divergence between the Python community and most of the rest of the "very powerful and succinct scripting language" communities out there (particularly Lisp, Perl, and Ruby come to mind). Python is, essentially, to this family of languages as Pascal is to the family of languages that includes stuff like C++, Objective C, and so on.
Some languages are designed primarily to empower the programmer, trusting that the programmer will be smart enough to avoid doing something suicidal with that power. Python strikes me, on reflection, as a language designed primarily to protect the programmer, trusting that the programmer will be smart enough to use it effectively despite limitations.
. . and thus, I have more explanation and understanding of why Python just "feels wrong" to me. One of the reasons I like Perl is that it doesn't limit me "for my own good". I guess I prefer a swiss army chainsaw over a plastic scalpel. [1]
> Matz has put us in great danger. But Rubyist are okay with it I guess. > I am strangely at peace with this perilous language in my home!
> Superman does dangerous things to solve problems, too. He'll bend a > street pole around a villianous guy. People, stop cheering.
Nice to know your emails are as entertaining as your excellent Ruby tutorial.
[1] No offense intended to the "plastic scalpel" contingent. There's nothing objectively wrong with precision wedded to safety limitations. I simply find it to be subjectively distasteful.
