Diff of opinion on dynamic stuff

[Drew Mills]

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

Just curious.

Drew

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Diff of opinion on dynamic stuff"

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

matz.

 

[Ryan Leavengood]

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

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]

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

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

 

[why the lucky stiff]

"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]

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

 

[Joel VanderWerf]

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

 

[Ryan Leavengood]

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]

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.

Steve

 

[Chad Perrin]

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]

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

I think you're probably right, and it's a valid concern. I just don't
think it's a valid reason for eschewing Ruby.

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.

That's really only because while it might take a ten-line change to do
the same thing in Pascal, that one line in Ruby has the functionality of
about twenty lines of Pascal code. There are things I like about
Pascal, but this isn't one of them.

By the way . . .
I have, in the past, found myself thinking Python might be the Pascal of
scripting languages, and you got me thinking about that again.

 

[Bil Kleb]

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?

My code goes into maintenance mode almost as soon as
I've written 40 lines, i.e., I try to go depth-first
and then flesh out the skeleton as priorities dictate.

This is all done while creating a safety-net, a custom-
application debugger, through test-first development.
(Note: I've never had need of Ruby's debugger.)

The maintenance folks (me initially) are left with
executable, non-lying specifications for how everything
should behave and recipes for building new safety net.

Later,

 

[James Britt]

Bob Hutchison wrote:
...

Just be careful where you aim that thing.

Oh, inspiration for Yet Another Ruby Slogan:

Ruby: You'll Shoot Your Eye Out.

(Mad props to Ralphie, too.)

James Britt
--

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

 

[Brian Takita]

------=_Part_14625_32277111.1135310629857
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There seems to be alot of industry inertia on static time tools. Better
runtime tools would make a dynamic language such as Ruby more mainstream.

A number of people have proposed that the runtime tools can work with good
unit tests in place to exercise all of the code paths.

The breakpoint library is a good start but there is more potential. For
example, a tool that analyzes the runtime paths and graphs an object's
dependencies would be nice.

 

[dblack]

Hi --

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.

I've had for a long time a kind of semi-formulated idea about all this
in my head, and have never expressed it clearly. Let me try, and
probably fail.

In the Perl world, there was ("was" as in, I'm not in that world any
more) a perennial sense that all this "shooting in the foot" stuff was
a kind of test of personal resistance and fortitude. It felt
sometimes like the power of the language was mainly serving to allow
people to demonstrate how careful and wise they were. I don't say
that the best Perl programmers fell into this pattern, but in a wider
sense it definitely seemed that knowing about the "rope", and
maintaining a healthy distance from it, was a kind of badge of honor.

In Ruby, I see it differently. This is where I start having trouble
expressing it. It's a kind of wish that the gravitational forces be
aligned differently: instead of showing one's strength by pulling
away from the vortex, perhaps the powerful things in the language
could be *used* in productive ways, so that one falls *toward* them,
but without danger.

I'm not sure what this means, in practical terms.


David

--
David A. Black
(e-mail address removed)

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black

 

[Matthew J Desmarais]

Bob Hutchison wrote:
...



Oh, inspiration for Yet Another Ruby Slogan:

Ruby: You'll Shoot Your Eye Out.

(Mad props to Ralphie, too.)

James Britt

Holy Crap. If that were to end up on clothing, I would buy it. I mean,
I'd have all my Christmas shopping done by now.

Cheers,
Matthew J Desmarais

 

[Bill Guindon]

Bob Hutchison wrote:
...



Oh, inspiration for Yet Another Ruby Slogan:

Ruby: You'll Shoot Your Eye Out.

It is indeed "The Red Ruby BB Gun"
Well done!

 

[Doug H]

It is indeed "The Red Ruby BB Gun"
Well done!

A BB gun doesn't cut it though.
Ever seen the movie Training Day?:
http://img456.imageshack.us/img456/3705/trainingday8ry.jpg

 

[Isaac Gouy]

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.

Yes, the equivalent of "method_missing" has been used for many things
in Smalltalk. Glorifying in how we can hack "doesNotUnderstand:"
avoids having to admit that there's been a problem with the language.

"This comparison highlights that the most commonly used technique based
on the specialization of the doesNotUnderstand: method is not the best
one. As a first explanation of this situation, one should note that the
ability to directly execute a method has only lately been introduced in
the interpreters (methods valueWithReceiver:arguments: on
CompiledMethod class in VisualWorks and
executeWithReceiver:andArguments: in IBM Smalltalk). Moreover, this
comparison shows that the techniques based on VM lookup method or
method wrappers should be considered by more programmers than it is
currently the case."

"Evaluating Message Passing Control Techniques in Smalltalk"
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca99aMsgPassingControl.pdf

 

[Ezra Zygmuntowicz]

It is indeed "The Red Ruby BB Gun"
Well done!

Well you can shoot your own eye out but just remember one thing.
Rubyists don't throw rocks at dogs.

-Ezra