[Note: I don’t mean to pick on you, Stuart, but you brought up a lot of points that I wanted to argue, I actually really enjoyed your post, and there isn’t anything personal about this. But I know that I can be a bit abrasive at times, so I do apologize if I come off wrong here. To make up for it, I’ve tried to give you some google juice :) ]

After reading comments and posts in response to my Python post, I’m thinking that I ought to clarify a few things.

Thing One

I still think Pink Floyd sucks the big stinker. Let’s not make any mistake about my position where that band of pompous ding-a-lings is concerned.

Thing Two

I mentioned that I hated having to add self to parameter lists for method declarations. It’s been mentioned on Stuart Langridge’s blog, as well as in the comments here, that C# can be targeted for similar pointless typing exercises, and most notably in the curly bracket ( {} ) department.

In my post, I was basically complaining that, in spite of its clean start, Python still managed to come along with some pointless syntactic thingy-dingies. C#, on the other hand, is clearly a C-like language, and some archaic bits were carried over.

That said, self requires a lot more typing than { or }.

I’ll admit that I am no longer toeing the line of petty concerns, but have leapt right over it, leaving my dignity on the other side of the fence.

I hope I don’t let myself get dragged into an argument in which a few of us actually attempt to figure out which language requires more keystrokes.

And, by that, I mean that I hope I do. I just don’t want to admit it.

But it would all be beside the point. The point is this: C# is an extension of the past whereas Python is a very modern creation, and the choice was there to make it uber-clean.

A choice was made.

It was the wrong one.

Thing Three

Stuart Langridge left a comment in Schwuk’s blog in which he mentions that self doesn’t have to be in a method declaration’s parameter list.

Great, but not including self makes the method static.

This would be useful if, oh, I don’t know, 98% of my methods were static, but they aren’t. It’s the other way around.

This strange bit of syntax makes me think that it’s preferred that methods be static, as it’s more difficult to create instance methods.

Maybe that’s good for small bits of scripting, but what if I want to write an actual application?

Does anybody know if there’s a way to create global variables in Python? I think they’d compliment this feature well.

Anyway, a static keyword would have been nice.

Thing Four

Also in Stuart Langridge’s comment in Schwuk’s blog is this argument:

The fact that Python can work procedurally as well as object-orientedly doesn’t seem to me an argument that it’s not a good programming language. The simple answer is: don’t do that, then.

I just don’t agree. Go one way or the other, but don’t give people the choice of either. Not because I don’t think it can be done, but because I have little confidence that it will be done, and I, along with swarms of other people who were scarred from this aspect of VB6, have developed an alarmist type reaction to this mode of coding.

Choice is almost, but not quite, as overrated as Pink Floyd.

Choice sounds great in a warm and lovey-dovey “free-as-in-speech” way, but in reality makes decisions more difficult, and leaves people stuck, staring at a screen, wondering how to proceed. This is fine for things like spoken language where expression and mood are important, but not in a programming language where intention should be clear.

And now, if you’ll all excuse me, I have a flame-retardant suit to don :)