Home Original page

UserLinux chooses Python as "interpretive language" of choice

Sean Ross frobozz_electric at hotmail.com
Sat Dec 20 12:00:36 EST 2003 
"John Roth" <newsgroups at jhrothjr.com> wrote in message
news:vu765jfp9esl0f at news.supernews.com...
> a third is the ability to forget the empty parenthesis after
> a function/method call that doesn't require parameters.
>

Hi.
Every time I see that feature in Ruby I find it appealing - and then I don't
(which is kind of how I feel about the language as a whole). I find it
appealing because, well, like you've said, the operation doesn't require
parameters, so why clutter up the code with unnecessary parenthesis? And if
I only ever read my own code, and I was sure I would always know what I had
been doing in older code, I might be okay using that feature. But that's not
the case. I do have to read other people's code, which means (in this case)
I have to decipher, on each occurrence of

a

whether that is a variable or an implicit operation call (if I care about
that sort of thing, which I might). In Python, it's a binding (unless it's a
property "obj.a" in which case it's still a binding to a descriptor but that
gets invoked during look-up, so ... have I lost my leg to stand on there?).

I suppose I just prefer to know, from reading that line of code, without
tracking back into other parts of the implementation, or running it to find
out, whether a is a variable or an operation. But, then, properties can
obscure the issue in Python just as well, so I don't think this argument has
much steam (unless I advocate losing properties - which I really don't).

So, I'll address a slightly different but wholly related issue. In Python,
when I want to pass a function, method, or object as an argument, I do so by
name:

callable(function, method, obj)

The names in the argument list are bindings to the object - in this case to
a function, a method and some other type of object. Using the name of a
function or method does not invoke it, so I can pass these operations by
name without resorting to disambiguatory syntax introduction. Not so in
Ruby: because, there, the names function/method would be found (during
lookup) to refer to callables that take no parameters, so Ruby would invoke
them - which is not what we want. To get around this, Ruby introduces
:function, :method - which is not so terrible, I suppose. It's a trade-off
imposed, in part, by the desire of the language designer to allow for a
cleaner parameter-less method invocation. So, they've cleaned up one thing,
only to dirty up another. And Python has done the same thing, only they've
cleaned up name referencing rather than parameter-less callable invocations.

Which is better? Having to say a() explicitly when you wish to invoke a
callable, or having to say :a when you wish only to refer to the object and
not invoke it? Well, If we just go by syntax, :a uses one less character
than a(), so that could be a plus. And :a is very explicit (once you know
what it means) - you know you're using a name reference (correct term?).
But, when a and a() can both mean the same thing, or different things,
depending on the context ...

a = "variable"

def a
    "method"
end

puts a
puts a()

# output
variable
method


 ... well, for me, that's not such a great thing.

Part of language design appears to be about trade-off. And part of language
preference appears to be about choosing the language that handles most of
those tradeoffs as you would prefer (which can save you from having to write
your own). I think I prefer that callable invocation be done explicitly, so
that I may recognize it as such in my, and other people's, code. And I think
I prefer not having to disambiguate name referencing via arbitrary syntax. I
think that's what I prefer - and yet I see the allure of the "Ruby Way".

Why use parenthesis for an empty parameter-list, when you don't have to? To
be explicit. Why is that preferable? Because it's explicit? Um. Try again.
Because explicit is better than implicit? Begs the question. Because
ambiguous code requires you to expend more time reading to understand than
does less ambiguous code? Hm. I don't find the code ambiguous, but even so
the ambiguous code might take less time to write, so the overall time may
balance out. People read code more often than they write it, so the balance
would tip towards those who must read the code. Do they? Prove it. I site
such and such a study. Well, I write more code than I read. Then you musn't
be a very good programmer... and how could you write more code than you
read? Do you not read your own code? You know what I meant, and who're you
calling a bad programmer? ...

And so on ... ad nauseum ... much like this post ... heh

Sean
More information about the Python-list mailing list