Some time back I switched to my own homegrown software package for running this site and a couple of others. For the most part it's been a success, although my own development of the software dropped off steeply once I hit a "good enough" level of features. Then, not long ago, my hosting company revised how scripts ran on my server, and my blog software ... well, it didn't break, exactly, but let's say it dropped from warp speed to impulse drive.
I finally got sickantired of this, and so lifted the lid to see how I might make things better. In truth I was bracing for a weekend's worth of tinkering to get the damn thing running, but it turned out to be a mere five minutes of work. A little like your car looking ominously dead, when all that happened was the battery cable popped loose. (Mr. Sulu? Warp Seven...)
What struck me about the whole experience in retrospect was how I might not have been able to make it a five-minute repair job if not for the months of accumulated experience I'd stockpiled beforehand. The fix involved knowing about a few points of how modern Python-powered websites work, and which I had mercifully had the foresight to engineer into my own software for the day when that solution became viable.
I get, on a gut level, why some people just flee this scene screaming and take up insurance sales or what have you. Information technology is such a hairy, messy Gordian knot of standards and methods; that any of this works at all is miraculous. A big part of that is because it wasn't planned or designed; it evolved one clumsy step at a time, and its evolution was guided by forces as indifferent and malevolent as they were beneficial.
Time and again, wise and well-meaning people have proposed a kind of clearing-of-the-decks. Projects like Oberon were intended to remove all the legacy cruft from our IT stacks and free ourselves from the burdens of buffer overruns, off-by-one errors, and null pointer references. But none of this stuff has gone anywhere, because nobody really wants to drive a bulldozer over everything we already have. (Utopian solutions are great for what they aspire towards, not for what they actually embody.)
A big part of why I picked Python for all my current and future software products was because of the balance it struck between this kind of Utopian progressivism and the need to work with what we actually have. The language is sane in many ways, and if the cost of that kind of sanity is a little less performance, I'll live with it. (And given how ridiculously fast computers are today, that's not asking me to give up more than an angel's share anyway.)
New York City
Other Lives Of The Mind