Death of Design
At the time I'm writing this, the design of my site is minimal. I've deliberately chosen xhtml 1.0 strict as the markup for my pages, and there are currently exactly four lines of css, the purpose of which is to present the tags for each entry on a single line. In markup, they are noted as an unordered list, which, semantically, tags are.
Philosophically, my approach is to minimize the use of styles, relying on them only to make the page more readable, while maximizing use of semantically significant markup, such as an on ordered list of tags, instead of whitespace-separated, inline links. It's kind of like CSS Naked Day, but it's everyday.
This gives control back to the user where it should be, but also requires participation and a degree of savvy that users may not be used to. Users are given responsibility for using—users using, hmmm—their browsers to find a font size they find comfortable, for example. To a greater extent, users must take responsibility for their own experience.
It's similarly liberating for me as generator of the content. I'm not a graphic artist, and I'm certainly not interested it tweaking and retweaking the layout to make it work with ahem other browsers. I want to be reasonably confident that I've made the information available in the most convenient and easy to digest form, and then not worry about it. I have a gut feeling that if ease of use is accomplished, beauty of presentation will be a co-effect.
Unfortunately, we have been trained by corporate marketing experts to
expect data to be presented in a highly controlled and prepackaged
fashion. Content that is not presented in three non-resizable columns is
likely to be written off as unprofessional
or unreliable
.
We have been trained that real information is branded.
I've received mixed reviews so far, ranging from very clean
to
unpolished
to it renders so fast
to 1996 called; they
want their layout back
. I'll keep adjusting as
old features are reapplied and new features are added, but I don't
expect it will change much.
Stackless Python, Lunchtime Lightning, Dev Panel
After SWIG, I just stayed put for a talk on stackless python. I knew nothing about stackless before the talk, and I only know a little more now. I'm still digesting the ideas; it's exciting.
Over lunch, conference sponsors gave lightning talks
, five
minute mini-sessions packing loads of information into a little time
(with the overhanging threat of the mic being cut off when the timer
reaches 0:00). We heard interesting things about scientific programming
(SciPy) and development tools (bazaar, komodo), but the room was
electrified by the CCP Games
talk. EVE Online is built on a python (stackless!) infrastructure. The
demo they showed, though prerendered, earned the only ovation offered
during the lightning talks.
I'm now listening to the python dev panel, and the biggest discussion is about how python can be made to take advantage of multiple cores. The global interpreter lock makes this hard, and the limitations are not unique to python. The panel seemed to have the consensus that python that can move away from the GIL will be something other than CPython, maybe PyPy. (The panelists are CPython developers.) Argh, the pypy talk is going on opposite this one.
Question: What about bloat? (This was prompted by the keynote, which I'll write about later.)
One panelist (Andrew?) lamented that the language is changing, with
new features being added, leading inevitably to larger size. He wishes
that they could "quit monkeying with the language" and work instead on
the standard library. (Is python finished
? I wondered this in
2003, when list comprehensions were new. I mean, they're keen, but...
I wonder if this is the attraction of LISP. Its been done a while, ARC
notwithstanding.)
Speaking of core bloat, question: What needs to happen to get numeric stuff, like the array interface into the core? The numeric community needs to take the lead, submit patches, etc. Incremental changes are good, easier to review than large sweeping changes. Start as a library, popular, stable, that can be included in the "batteries included" distribution.
Question: What's the process to get a package accepted into the standard library? Step 1: Write it. Don't ask if you should write it, just write it. Get it accepted by the community. Follow the coding standards. Be ready to be the maintainer. It must be a general solution that is useful to the community at large. Documentation and tests must also be included.
Question: There's no mechanism for unloading a C extension. Should there be? There's not much call. There's no way to know of the extension is actually unused.
Question: Standard library vs. eggs. Setup tools will support eggs in 2.6. Should eggs replace large swaths of the standard library modules? Mmmmaybe.