[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Diff of opinion on dynamic stuff

Drew Mills

12/22/2005 9:23:00 PM

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.

-- http://blog.ianbicking.org/theres-so-much-more-than-...

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?

Just curious.

Drew
37 Answers

Yukihiro Matsumoto

12/22/2005 10:11:00 PM

0

Hi,

In message "Re: Diff of opinion on dynamic stuff"
on Fri, 23 Dec 2005 06:27:50 +0900, "Drew Mills" <drewmills@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-...
|
|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.

matz.

Ryan Leavengood

12/22/2005 10:17:00 PM

0

On 12/22/05, Drew Mills <drewmills@gmail.com> wrote:
> 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.
>
> -- http://blog.ianbicking.org/theres-so-much-more-than-...
>
> 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 ;)

Ryan

Bob Hutchison

12/22/2005 10:24:00 PM

0


On Dec 22, 2005, at 4:27 PM, Drew Mills wrote:

> 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.
>
> -- http://blog.ianbicking.org/theres-so-much-more-than-...
>
> 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.

Just be careful where you aim that thing.

Cheers,
Bob

>
> Just curious.
>
> Drew
>
>

----
Bob Hutchison -- blogs at <http://www.recursive.ca/...
Recursive Design Inc. -- <http://www.recursi...
Raconteur -- <http://www.raconteur...

Patrick Hurley

12/22/2005 10:31:00 PM

0

On 12/22/05, Bob Hutchison <hutch@recursive.ca> wrote:>> On Dec 22, 2005, at 4:27 PM, Drew Mills wrote:>> > 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.> >> > -- http://blog.ianbicking.org/theres-so-much-more-than-rail... >> > 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.>> Just be careful where you aim that thing.>> Cheers,> Bob>> >> > Just curious.> >> > Drew> >> >>> ----> Bob Hutchison -- blogs at <http://www.recursive.ca/hutc... Recursive Design Inc. -- <http://www.recursive.c... Raconteur -- <http://www.raconteur.info/>>>... think there are two conflated issues here. First open classes andtheir abuse and second dynamic method creation. I think they distinctenough they should be considered separately.Considering open classes, I find many of the conventions used inRails, once they are understood, simplify the resulting code. Giventhis, it is worth pointing out that Rails is fairly unique in Rubydevelopment being a mainstream library that does modify base classes.Additionally very few of the enhancements to the base classes are"non-obvious" even a non-programmer will recognize the purpose ofitem.pluralize. It is arguable and I would not disagree that this isstill thin ice. Using different Ruby libraries may cause issues—itwould be good if such changes could be better scoped. Still inpractice I have encountered none of the sort of problems I have wouldexpected. And unit tests are still the best medicineThe second issue of dynamic method generation (which I think was themeat of the above quote) seems more like a documentation issue thananything else. Consider a different framework that used a data file tocode generate a large number of access methods into a database,similar to the functionality which is dynamically generated withinActiveRecord—would this be the monkey patching that is so troubling?Similarly, while it can take some acclimation, who cannot understandcode like:item_list = Item.find_all_upc(upc)Yes, you would look long and hard to find this particular method inthe API, but once the convention is understood (as it should be byanyone who has developed in Rails for more than a day or two) it isvery intuitive.In the end, I think it is a matter of trust. Any programming languageworth using, can be used poorly. Ruby and Python are no exception inthis regard. Writing good code which by definition is maintainablecode by both first and second generation coders is difficult. Railsuses much of the power of the Ruby language to map the code to theproblem domain (database driven web applications).As always the devil is in the details. I would be very curious whichaspects of Ruby/Rails development in particular anyone thinks will bea long term maintenance issue.pth

why the lucky stiff

12/22/2005 10:37:00 PM

0

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

Doug H

12/22/2005 11:14:00 PM

0

Anyone who tries to reverse engineer ruby code into a different
language is bound to be frustrated.

Joel VanderWerf

12/22/2005 11:25:00 PM

0

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

Ryan Leavengood

12/22/2005 11:49:00 PM

0

On 12/22/05, Joel VanderWerf <vjoel@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.

Ryan

Steven Lumos

12/22/2005 11:53:00 PM

0

Chad Perrin

12/23/2005 1:46:00 AM

0

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.

--
Chad Perrin [ CCD CopyWrite | http://ccd.ap... ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.