Ruby Impressions

[Michael Chermside]

Adam Spitz writes:

> OK. Last thing that I want to say, then, since I've obviously offended
> people, and we're not going to get any further that way.


Adam, please don't feel as if your comments were unwelcome. I have been 
reading this threas -- at first just a quick glance to see why it was so 
active, but later with some real interest and hope of learning 
something. And the reason that I felt I might learn something was solely 
because of your contributions.

You did two things RIGHT: you addressed the *real* underlying question: 
"Why might someone prefer Ruby over Python?", and you did so in a 
*polite* manner:

> Thank you for all the responses. I learned a lot about Python just
> from reading them. And I'm impressed that there are so many different
> ways to accomplish this kind of thing.
> 
> But I have to ask you this: ...

So please don't be scared off by a few overly zealous defenders of 
Python practices...

> Ohh!  Is that a strawman argument?  Or the fallacy of the excluded middle?
> Perhaps the fallacy of the false dilemma?  Maybe even all three?  I never
> did remember the names of all the rhetorical tricks.  Basically, no one
> ever said what you propose here as the counter to your proposal.


...because some of us are listening carefully and hoping we can learn 
something. (Andrew Dalke: you made some interesting points, but don't 
ride Adam so hard!)


Here's what I have learned so far:

   1. Ruby allows fairly easy modification of some basic language
      features (like initialization).

   2. Various tricks allow you to do pretty much the same thing in
      Python.

   3. Most Python programmers don't use such tricks (except for the
      really simple/idiomatic ones like "__dict__.update(args)").

   4. The Python folks defend this saying "it's easier to read" (because
      you stick to standard idioms, even if they're a bit longer). The
      folks on the other side say "but the idiom's verbosity may conceal
      the fact that it's conceptually a single, simple operation".

Hmm... interesting when viewed that way. We AGREE that legibility of 
code is more important than brevity or cleverness most of the time. The 
hard part is to balance locality (use a simple, standard idiom so you 
don't have to look up the definition of something non-standard) versus 
generality (write a recompiler/class/metaclass/gizmo that provides a NEW 
idiom which describes what you're trying to do as a single method/ 
superclass/whatever). Anyone who tries to say it isn't difficult to get 
this balance correct either never bothers to consider such things, or 
they're an XP practisioner (if uses == 1: locality else: generality).

See-Adam-now-they-can-flame-me-instead-for-misrepresenting-XP-ly yours,

Michael Chermside