What's TOTALLY COMPELLING about Ruby over Python?

[Andrew Dalke]

John Roth
> All of the Ruby collections implement a .each method, which is essentially
> a version of the Visitor pattern. If I want to do something to every
element
> in a list or a dict (or any kind of collection,) all I have to do is say
> something like (using Python syntax):
>
> collectObj.each(<method name>)

Does that mean 'apply the method to each element of my
collection?'?  Does it return a new container or modify things
in-place?  Is it applied recursively?

Does it work on strings?  Are characters in Ruby also strings?
If so, and if .each is recursive, what's the bottom case?

> And you
> have to worry about distinctions between functions and methods. In other
> words, it's a mess compared to Ruby.

Where does that distinction come into play?  A method is a bound
function, kinda like a curried function with self.

I find C++ methods more confusing, because a reference to a
class method is unbound, when I almost always want it bound.

> Now, you can say: "We've got that with map()." Well, we've got it when
> your inputs are either lists (or implement the correct protocol) but the
> result is a list, it's not an internal modification to the object's state.

Ahh.  Are strings in Ruby mutable or immutable? ...  Yup,
looks like it's mutable.  From the FAQ

  def downer(string)
    string.downcase!
  end
  a = "HELLO"
  downer(a)
  puts a        #=> "hello"

In which case it makes more sense for this in Ruby than in
Python, since

"ABCDEFG".each(f)

can't do that much unless f modifies state, either as a bound
method or tweaking global variable.

Given that rather fundamental difference, an each method
in Python + code blocks wouldn't be any more powerful
than a for statement.  The following is possible

def each(container, f):
    for i, x in enumerate(container):
        container[i] = f(container[i])

but then it requires the container be indexable, which
is stronger than just being iterable.

How do Ruby's associative arrays work when the string used
as the key is mutated in-place?  Is it copy-on-write?

> To continue on this vein, Ruby directly implements Visitor, Observer,
> Delegate and Singleton. I don't particularly like the way it does some
> of them, but Python can't claim any one of the four!

The Python approach to a Singleton is called a 'Borg' class.
Described by Alex Martelli, it looks like

>>> class Borg:
...  shared_state = {}
...  def __init__(self):
...   self.__dict__ = Borg.shared_state
...
>>> x1 = Borg()
>>> x1.a = "Albuquerque"
>>> x2 = Borg()
>>> x2.a
'Albuquerque'
>>>

The other way  to get singletons is with a factory function,
which under Python wouldn't look different than a normal
constructor.  I looked at some Java code recently and
wanted to suggest a factory implementation only to realized
that would require a lot of 'new' removals.



> Granted, you can do a clean singleton using new style
> classes and the __new__() method,

See Alex's discussion at
  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531

as for why singleton (so that 'x1 is x2') is less important
than many consider.  Though I know I can't recall needed a
singleton for my code.  Maybe I have a different code style?
I've noticed a tendency of mine towards functional programming...

Anyway, others consider Borg a workaround for Python's
until-2.3 unability to support singletons, as with
 http://mail.python.org/pipermail/python-list/2002-April/096382.html

As for Observer, etc., I know they are simple classes so I
don't consider them all that important as a differentiator.

> It might be better to simply take the question at face value, rather than
> slanging Brandon. I don't find the personalities to add anything of value
> to the conversation.

Despite my best attempts, I find it almost impossible to slag someone
without including information to back up my view.  Eg, I thought my
numbers and trends of mentions of other programming languages was
pretty interesting, but I guess it was of no value to you.  :(

                    Andrew
                    dalke at dalkescientific.com