Re: [tlug] ruby and python in Japan

["Stephen J. Turnbull" <stephen@??>]

Edward Middleton writes:

 > The problem with derived classes is that existing classes reference the
 > parent not the derived class so you can't change a feature without
 > deriving all the classes associated with it.  There is obviously the
 > potential to misuse this feature, but it is useful when it is needed.

And monkey-patching is available in Python (AFAICT the term originated
in the Zope community, but my source is wikipedia which (a) can't
spell "guerrilla" and (b) clearly is based on iterated hearsay).
Pablotron sez the name comes from the Python community, but also cites
the Wikipedia article.

The OP said "casual"; you can't casually do surgery on an existing
class in Python, but you can do it without much trouble.

 > This feature can be very useful for both debugging

Python generally doesn't need it for debugging: introspection is part
of the language, and it provides an excellent debugger as well.  I
would assume both are true of most high-level OO languages (ie, not
C++ but surely Ruby).  And if you need it, monkey-patch.

IOW, Python and Ruby provide much the same features here, but they
apply different "spin control" to them.  There's an excellently
balanced post by Chad Fowler explaining the spin control.[2]  My
feeling is that what this points out is that Python is a more mature
language in terms of volume of legacy code.  Really, what is
monkeypatching but opening the Windows and letting "DLL hell" fly in?
I think that what you'll find (and sooner rather than later) is that
Ruby programmers will find themselves working in iterated frameworks
(don't know for Ruby, but in Python we have the Threes: Zope3 on
Twisted, and Mailman3 on Twisted), and they will curse the names of
monkeypatchers.  Cf Pablotron's "Rule of Monkey Patching".[1]

Ian Bicking's blog post and the ensuing discussion is a pretty good
summary at the abstract level, though he is obviously advocating
Python.[3]  Nevertheless, he doesn't ignore the Python community's
problems, so you can pick up on some of that here.

BTW:

I find Curt Sampson's argument that modern functional languages (ML,
Haskell) provide much more powerful abstractions than Python more
persuasive, but that's trumped by GvR's YAGNI.  Really, unless you're
writing something insanely abstract like an intelligent revision
control system (Darcs), you don't need the power of something like
Haskell.  And then, several people I trust are now advocating
Mercurial over Darcs.  Guess what language Mercurial is written in?
(No, not Ruby, but it could very easily have been.)

Footnotes: 
[1]  http://pablotron.org/?cid=1514

[2]  http://chadfowler.com/index.cgi/Computing/Programming/Ruby/TheVirtuesOfMonkeyPatching.rdoc,v

[3]  http://blog.ianbicking.org/theres-so-much-more-than-rails.html