Funny how people get weird about style issues. Me too, I guess. There's a certain territorial aspect to it. Combined with the intuitive Rightness of one style over another... the Rightness creates conflict, the intuition means people can't argue very usefully about it.

Seeing this, of course people decide that style isn't a useful thing to discuss. They get short about it, seeing it as troll talk.

I don't think that's quite right, though. I like systems because they feel right. I design systems intuitively -- and I think that's the way good design has to be done. You need to envision the entire thing, which has a certain gestalt aspect to it. You can't work towards a great design, except by experimentation and iteration. Even then at some point you simply have to arrive at it. It's all about feel. So I think the feel of something is very important. An elegant system feels good. That's pretty important.

Did some C programming today, which I haven't done in quite a while. First run at a small CGI program to interface with the Webware application server -- hopefully being in C it will start up considerably faster than the Python-based version. C is awkward, but I actually quite enjoyed it -- dealing with pointers and such is refreshing, and I haven't programmed in anything but Python (and a little PHP) for many months. Heck, I hardly even program shell scripts anymore... that'll get a person stuck in a conceptual rut.

But I'll be back to Python tomorrow, I imagine.

Spent yesterday writing testing documents for work. Oh, that hurts. It's like all the exactness and tedium of programming, but with absolutely none of the satisfaction. I felt like I was writing copy -- something I really should do for my website as well. Wish I could automate more of the testing... not sure how to do that for a website, though.

dyork: (tree program) os.path might use statcache, I don't know, but you may be able to optimize your code by using os.stat instead of islink, and isdir. It also would be more correct, as your current program seems to treat all symbolic links as directories. I think it's certain to save at least a little speed, maybe a fair amount (since stat's disk access is probably the biggest performance issue). Also, it's nearly as easy to pass the full path (relative to cwd or not) as it is to change directories, and this will probably also be a little faster. I think this is a case where the smallest version of the program you can write will be the fastest (as long as that means that each file gets stat()ed only once).

Spent yesterday reading through the code for Webware. I understand it a lot better -- the factoring reminds me of Smalltalk. Wrote a document trying to describe how it all fits together.

I realized that most documentation fits two models: tutorials/users guides, and reference documents for the developers. I think that leaves a big gap, for someone who wants to become a developer on the project, and is already a programmer. Being confronted with a pile of code can be very intimidating, not to mention frustrating. You change a piece of code only to find out it doesn't get called when you think it will, or you search in vain to find the code that corresponds to a certain behavior -- you may never find it, the section of code you imagine may actually be scattered across the entire program because you have the wrong model as to the inner workings. Reference documents don't help you there. At best they infer a model, in a vague sort of way.

Webware was pretty bad that way. A lot of generality, classes are often not referred to concretely (since part of customization can be creating subclasses of core components), and a mess of methods passed back and forth. Not so bad when you understand it, but I had to struggle some to figure it out. (that said, I think it is well programmed and very compact... I wouldn't want to even start were it programmed in Perl... it's just complicated and has a lot of hooks for future growth).

I always enjoy code maps, more people should write them. They address concretely what's probably the most important part of the program -- the architecture.