Confessions of a Python fanboy

[Steven D'Aprano]

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 
obvious one.)

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__
<type 'int'>



>>>> 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 
important, because 

(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 :)




-- 
Steven