From: Mark Hubbart <discord@...>
Date: 2004-04-02T16:44:20+09:00
Subject: Re: deciding between ruby and python

Hi,

I get the feeling I may be feeding a troll, but some of your comments 
left me feeling unable to resist replying, though I probably should 
ignore.

On Apr 1, 2004, at 1:04 PM, Ville Vainio wrote:

>>>>>> "Hal" == Hal Fulton <hal9000@hypermetrics.com> writes:
>
>     Hal> I'd have to disagree. join, since it produces a string, 
> obviously
>     Hal> knows about strings even though it is not a string method.
>
> And hence, the sequence knows about strings. The Ruby approach is
> making a special case of strings, while the Python approach doesn't.
>
> I'm not saying this is a question of big importance - we have lots of
> people in Python camp who don't like ''.join() either. It just seems
> most sensible for me, even if it isn't obvious for newbies. I think
> it's a situation where Python errs on the side of pure OO instead of
> practicality.

No. When implementing a join method, you have a choice: let Strings 
understand something about Arrays, or let Arrays understand something 
about Strings. Does it make much difference either way? Should we 
choose to make a special case of Strings, or Arrays?

I feel that it makes more sense tell an Array "join your elements using 
this string" than the other way around. You feel differently. :) I 
guess it's a matter of taste.

>
>     Hal> As for x.y, I think it general we are "performing operation y
>     Hal> on object x" -- and it seems clear to me that join is NOT
>     Hal> acting on ' ' (which is only a single item anyway).
>
> But that's context dependent knowledge. Python is very explicit and
> always requires () which is a 'call' operation on an object. I think
> that's a very small price to pay for first class functions.

As has been argued before, where pythoners will pass a function, 
rubyists pass blocks. In the rare occasion where we want to pass a 
method, there's Method.new, which converts a block into a Method 
object, or the instance_method method which lets you unbind a 
pre-existing method. But for most things, we just use blocks. What's so 
special about using methods?

>     Hal> Let's channel this discussion more productively: Why should I 
> want
>     Hal> first-class functions? Honest question, no sarcasm.
>
> You can just pass functions directly to anything that wants a callable
> object. Functions and methods are objects like everything else, you
> can pass them around and store them any way you want.

see above...

> You can use higher order functions, which is critical for FP.

again: blocks? Can you give an example where blocks don't fill the spot 
functions take in Python?

moving to another email (regarding calling to_s on array items when 
joining:

> I mostly meant that the sequence has a special case for the list of
> strings. We have __str__ in Python too, but ''.join doesn't call it:
>
>>>> '-'.join([12,13])
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: sequence item 0: expected string, int found
>
> Calling to_s() seems kinda brutal from the Python POV. Perhaps this is
> one of the areas where Ruby chooses the follow the Perl school of
> Convenience.

it makes perfect sense. Ruby uses duck typing... so when you call join, 
it assumes that you want the array items interpreted as strings. It 
calls to_s only to ensure that it has the proper concatenation methods 
available. If the item doesn't implement to_s, an error will be raised. 
This isn't a perlism, it's good old-fashioned duck typing. (well, maybe 
newfangled duck typing... I'm not sure :)

>     Jim> performed on these functions that produce new functions.  A
>     Jim> higher order function (in my perhaps flawed understanding) is
>     Jim> a function that takes other functions as operands.
>
> .... or returns new functions.


sorta like this? (remember, we use blocks here)

   def combine_blocks(one, two)
     Proc.new{|*args| one[ two[*args] ] }
   end

this returns a new block that combines the two blocks passed.

> Yes, Ruby and Python are not all that different. I guess most Ruby
> fanatics

There's only one fanatic plainly visible here...

> would be quite happy with a forked version of Python. Adding
> most of the features Ruby people love would be quite easy (some, like
> sequence.join would be trivial), it's just that the core Python
> developers have chosen not to implement them for one reason or
> another.

I think I caught a whiff of elitism there... Perhaps Pythoners would be 
happy with a forked version of Ruby? I doubt it. And I doubt that 
Rubyists want a forked version of Python.

just my two measly cents.

--Mark