brainwagon

The Python Daily URL! feed has had quite a few articles lately on the so-called “decorator” syntax. I must admit, I’m not really up on the controversy, but I was amazed that even after reading three or four posts, I still couldn’t figure out what the intended utility of the new feature was supposed to be. I suppose it’s because I’m hopelessly out lunch with respect to certain OOP practices, but still: I’m not a programming language newbie.

Whether I’m right or not, it does not bode well for the trend that Python is taking. I’m not the only one who is noticing. Python is sprouting new features which increase the spartan simplicity and expressive nature of the underlying language, complicate it’s implementation and give very marginal utility in return.

Personal (if second hand) anecdote: While attending the University of Oregon in the late 1980’s, I had the pleasure of having Will Clinger as one of my professors. Will was the author of the Revised Report on Scheme: the master work which describes what Scheme was, what it required and gave the semantics for the language. It was a remarkably terse document. In contrast, the specification for Common Lisp was being worked on by Guy Steele. The Common Lisp specification was large, cumbersome and while Common Lisp was more feature-rich, it seemed like a lot of work to implement all facets of the language, and there were many things included in the specification which were of marginal utility. Sound familiar?

Clinger described the situation to me thusly: when presented with a potential new feature for the Scheme specification, he asked himself two questions:

• Can this feature be implemented using machinery allready in the Scheme specification? If yes, then it is better to implement it that way, and not pollute the base language. This criterion eliminated unnecessary language changes that were largely semantic.
• If this feature couldn’t be implemented using the existing language, then is this feature the best idea which implements the desired effect? At the time, they were working on the Scheme macro facility, and they were working very hard to make sure that they implemented the best macro facility they could.

By contrast, Clinger characterized Steele’s approach as roughly “If each additional feature is of some use to somebody, and only marginally complicates the language, then who am I to oppose?” This is no doubt at least partly due to the business forces which already were heavily invested in various versions of Lisp, and therefore had a vested interest in seeing their own pet extensions merged with the language specification. Still, this “default is to accept” notion is very damaging to the tidiness of language specifications.

I fear that in the future, some of Python’s expressiveness will be clouded by dozens of features which are of marginal utility. We shall see.