Confessions of a Python fanboy
steven at REMOVE.THIS.cybersource.com.au
Tue Aug 4 11:28:50 CEST 2009
On Tue, 04 Aug 2009 10:03:53 +0200, Bruno Desthuilliers wrote:
>> Disadvantages: your code is filled with line noise. It's an arbitrary
>> choice between @@ meaning instance attribute and @@ meaning class
>> attribute -- there's no logical reason for choosing one over the other,
>> so you have to memorise which is which. It's easy to get it wrong.
> So far that's something I have no difficulty living with.
I don't like arbitrary symbols. Most people don't -- that's why "line
noise" is unpopular. It's hard to read, hard to write, hard to maintain,
and hard to talk about. The more line-noise, the worse the language.
Of course, *ultimately* every symbol is arbitrary. There's no reason why
"2" should mean the integer two, or "list" should mean a sequence type,
but some symbols have such a long history, or have some other connection
(say, with human languages), that the arbitrariness is lost. For
instance, "+" is the obvious, non-arbitrary choice for the addition
operator in any programming language using Latin symbols, and probably
any programming language on Earth. (Not the *only* choice, but the
I have a similar dislike for decorator syntax, because "@" ("at" in
English) has nothing to do with decorations. It's an arbitrary symbol.
One might argue that "$" would have been a more logical choice, because
we turn numerals into currency by decorating it with a $ sign. (At least
in the US, Canada, Australia, and a few other countries.) I use
decorators all the time, and they are a fantastic invention, but the
arbitrariness of the @ syntax is a negative. Oh well, one negative out of
a whole lot of positives isn't too bad.
At least I only have to deal with *one* such arbitrary symbol that needs
memorizing. There's no need to distinguish between @@function_decorator
and @class_decorator (or should it be the other way around?). Similarly,
Python's choice of syntax for attributes is consistent: object.attribute
works for everything, whether object is a class, an instance, a module,
and whether attribute is callable or not. You can even use it on ints,
provided you are clever about it:
>>> 42 .__class__
>>>> Somebody who knows more Ruby than me should try writing the Zen of
>>>> Ruby. Something like:
>>> (snip childish parody of Python Zen)
>>> Steven, is that any useful ?
>> It made me feel good.
> Why ???
> You don't like Ruby ? Fine, don't use it. Period. I can't see the point
> of all these pissing contests.
Criticism of a language is a pissing contest?
Yeah, okay, I was a tad dismissive. I un-apologetically jump to strong
impressions about languages based on minimal use -- but I'm also willing
to change my mind. Ruby certainly looks to me like it has some nice
features. Syntax that looks like Perl isn't one of them though.
>> Just because Smalltalk had a particular (mis?)feature
> You can drop the 'mis' part IMHO. The point of code blocks in Smalltalk
> is that once you have something as powerful as the message+code blocks
> combo, you just don't need any other 'special form' for control flow.
Well, maybe, but remember, programming languages are only partly for
communication to the compiler. They also have the requirement to
communicate with human programmers as well, and that's even more
(1) humans spent a lot more time working with code than compilers do;
(2) human programmers charge much more money than compilers do;
(3) and you can modify the compiler to suit human needs much more easily
than you can modify programmers to suit the compiler's needs.
So I'd ask, does Smalltalk's message passing model match the way human
beings think? If not, then that's a good sign it might be a misfeature.
>> doesn't mean that
>> other languages should copy it.
> Nope. But OTHO, Python is famous for all the features it copied from
> other languages !-)
Absolutely! There's nothing wrong with copying *good* features :)
More information about the Python-list