mwh's blog for 2004 October 9 (entry 0)

(2) Sat Oct 09 2004 14:51 CET-1CEST not messing up, AOP, PyPy:

Saw a link on Advogato to an Alan Cox interview about writing better code.

Nothing terribly exciting, but he stresses the point that the quality of tools and interfaces has a large impact on the quality of code. People will always make mistakes; we shouldn't make it easier to foul up than it has to be.

He also talks about automated verification tools, using the example of checking a lock is released on all code paths out of a function. There's a gap in the market for a similar tool to check the reference count manipulations in CPython. Although reference counting is conceptually simple, it's a classically bad interface in some ways: no matter how careful people are, there just will be reference counting mistakes in new C code in each major release cycle of Python. I've written some tools to watch for reference leaks while running the regression suite, and so long as you run these fairly often (not every day, they're pretty slow) it's not that hard to find and fix the bugs -- because you can be pretty sure they'll be in new code. I'm not sure automatic verification is the right solution, though.

A better solution, perhaps, would be to not write the reference count manipulations at all: if you write the code in Pyrex, say, and you trust the author of Pyrex, you can be confident that the generated C code will get this right. You're exchanging a wide-spread, fairly simple problem for a localized, harder problem that someone else has already solved. This has to be a good thing.

So, AOP. One reasonable definition of AOP is "a set of tools and techniques to make programming on the Java platform more bearable". I'm interested in the other one: the idea that each decision involving writing a piece of software should be reflected in as few places as possible. The AOP crowd usually use logging as their example. This is a crap example, IMHO -- memory management is a much better one (unfortunately, it's not one the AOP crowd's tools can do anything about AFAIK). The decision to use reference counting in CPython's implementation is emphatically not localized -- it's reflected tens or hundreds of times in almost every C file in the source. Another example is that the seemingly less contentious decision for a function call in Python to be implemented as a function call in C makes implementing interesting control flow -- coroutines, restartable exceptions, etc -- very much more difficult.

So, what can be done? Well, one idea is to take a specification for the Python language and from that generate an implementation. Hopefully, this generator can be designed such that aspects such as memory management model, allowable control transfers and even target platform are localized in the AOP sense. Now, how do you specify the Python language? Well, you could write a Python program that implements the Python language... which brings us to PyPy.

I should probably turn on drafts for NewsBruiser. I apologize to anyone who read this entry while I was still rewriting it..

Comments:

Posted by Ian Bicking at Mon Oct 11 2004 21:41

After trying, I've yet to really figure out AOP. As far as I can see, it's macros for languages that don't have macros. As such, it would probably be useful in C (which has macros, but not very good macros).

Python also doesn't have macros, but I've yet to see a really compelling argument for them. You can generally do the same things in other ways, where "the same thing" can include a resistance to bugs. There's still techniques you have to use -- which may be non-obvious -- to avoid bugs, but it's not for a lack of features, nor I think are the correct techniques particularly burdensome.

Posted by Michael Hudson at Tue Oct 12 2004 13:49

Well, yes, that's the "set of tools and techniques to make programming on the Java platform more bearable" definition of AOP. Maybe there should be another buzzword for what I mean -- but the idea that each `aspect' (in the English language sense of the word, not any buzzwordy meaning) of a program should be controlled by the smallest amount of source makes sense to me. That's what I was talking about.

Obsessing about source code transformation or cutpoints or whatever misses the (well, my) point.