Not only do I think that the editors of The Economist produce one of the finest publications on this planet, but their readers seem to be an especially insightful bunch, too. For evidence, check this letter to the editor in response to an article about the University of Oklahoma fighting campus drinking:

The UK definitely sounds like a place to go for a few semesters of, er, intensive study…

Paul Robinson posted to RISKS on the merits of component architecture last week, reiterating the old beliefs that software development should evolve from a craft to an industry.

For some reason it’s perfectly acceptable for a trucking company to build an
accounts receivable application from scratch but nobody in their right mind
would expect them to build their own trucks.

This week’s RISKS digest consists almost entirely of rebuttals and comments on this post, and they’re quite interesting. There’s various rants about the idea that reusable components are the silver bullet for software problems, and they’re pretty good.

What OO has done to the development of software engineering is devastating.
Instead of continue to develop more advanced languages we got stuck with
half-assembler languages like C and followers. A compiler for a high level
language (re-)uses code templates. A compiler for a more advanced language
could reuse even larger chunks of code, without any need for a programmer to
try to find the code in a catalog.

There’s a somewhat off-topic, but still interesting entry advertises the Raskin Center for Humane Interfaces, a newly founded project of, well, Jef Raskin, of, well, Humane Interface fame:

And then there’s the fun little quote about people thinking that everything besides software is insanely reliable:

Years ago I quoted to an architect Weinberg’s line that “If architects built
buildings as programmers build programs, the first woodpecker to come along
would destroy civilization.” “Oh,” she said, “but that’s just how they do
build them.”

I think of myself as a pretty rational person, as outlined on this blog a number of times. I believe in a number of systems (evolution, free market economics, the scientific method and an open society) whose emergent properties combine to produce progress, however undirected it might seem. All of these systems share a fundamental concept – they produce "individuals" (living creatures, products, theories, institutions) and some feedback mechanism coupling the "survival" and "reproduction" of these with an evaluation process to determine their "fitness".

While these systems are superficially easy to explain, they play out in amazing complexity in the real world and are thus not very easy to apply in individual cases, yielding rich fields of scientific activity for those trying to explain observations through these laws.

What does all this have to do with dress codes, you ask? Well, they’re puzzling me. I believe that all the observable traits of our society can be assigned a kind of "evolutionary score". Exact numbers, if they are knowable at all, are probably hard to determine, but the notion yields a classifier for all kinds of traits – "advantageous", "neutral" or "disadvantageous". Even assigning such a classification to individual traits, however, is not at all easy. Jared Diamond does a great job of showing these systems in action in his books.The Third Chimpanzee is full of interesting examples from the realm of evolutionary biology, and Guns, Germs and Steel explains the history of human societies through the interplay of several economic and biological factors. The Third Chimpanzee especially is abundant with examples of behaviour that would seem absurd at first sight, but provide positive "evolutionary value".

So, I’d like to assign evolutionary/economic/social value to the peculiar habit of requiring people to wear a certain type of attire for some activities. I can see no obvious reasons – just because I’m wearing jeans and a tee shirt with a geeky message on it, this doesn’t actually say anything about my knowledge of finance, my understanding of classical music or my intent to spend a lot of money on fancy drinks. However, the purveyors of bank jobs, opera tickets and night clubs tend to believe that wearing a suit is a valid economic signal. Are they right? I don’t think so. My theory is that clothing is an invalid economic signal because it can easily be faked. I assume that the existing dress codes are simply traditions that developed in a time when the social and economic status of a person was readily discernible from their appearance, and that they should eventually disappear in a society where you can buy two suits a month from your unemployment benefits. If I’m right, then we should see these codes receding, and there is really some anecdotal evidence to that point – at least in the tech industry, you’re more likely to get strange looks than extra recognition if you show up in a suit to a job interview, and music critics note that classical concerts fail to appeal to a younger audience because of their stuffy atmosphere. However, my Google search to find some research on this issue still mostly returns links to institutions’ dress codes, and as recently as 1985, Germany’s current foreign minister could cause an outrage by appearing to a his inauguration in casual dress and sneakers. Also note that the same minister is currently mostly seen sporting the required three piece suit.

I’m curious – is there research somewhere or a good theory of an actual value of such behaviour, or is it just a self-perpetuating social trait that is bound to be out-competed sooner or later? If you know a good starting point for education on the subject, please comment! In the mean time, I’m keeping up my personal dress code policy of "clean and comfortable", and the refusal to dress in funny-looking uncomfortable stuff just because someone else expects me to. With the exception of a few appearances at my former school‘s drinking-event-disguised-as-a-ball, I’ve been able to pull this off quite consistently, and I intend to stick to it until I get a rational explanation of what the point of dressing up is supposed to be (other than fulfilling someone’s expectations). Again, if I’m missing something, please let me know!

BoingBoing points to a blog post ridiculing “Intellectual Diversity”. Can we postulate that the label “ID” is generally reserved for right wing fundamentalist propaganda? Nope, unless you can explain how that one fits in.

For another great point on the second kind of ID, see here (with good comment, too) or the NYT directly, if you use bugmenot.

Shit. Right when the world is starting to look ever more Nixonesque again, the Doctor decides to call it quits. Truly sad news. Via Emergent Chaos.

Ah, this weekend reminds me of the good old days. I spent most of Friday night and Saturday shuffling billions of xterms and digging through C++ code in search of an elusive bug that should have been simple, but obviously wasn’t. Some sockets that should have been closed in the depths of a class library never were, and I couldn’t figure out why. The missing close call was hidden deep in a virtual constructor hierarchy, and I got downright weird behaviour, like a class executing its own destructor and its immediate base’s destructor, but not the rest of the hierarchy to the root.

After about 10 hours of tracing, debugging and reasoning, I accidentally ran the release build instead of the debug version, and noticed everything worked fine there. The other way round wouldn’t have been too exciting, a forgotten init-to-NULL or something along these lines is all too common in C++. Normal operation in release mode and a broken debug mode, however, surprised me.

This is where things got downright weird. I modified the build system to remove the differences in the build settings between the debug and release versions, the problem persisted. I compared the involved code in the shared libraries, and they were essentially identical (different names, but identical objdump -dC output). The test suite executable, however, produced entirely different disassembly when linked with the "debug" libraries. I didn’t bother to investigate too closely (might have been just different relocations screwing up the objdump diff) – at that point I had become convinced that something was wrong with my environment.

I decided to install g++-3.4.4, since I vaguely remembered hearing bad things about 3.3, and the whole virtual destructor hierarchy thing was starting to look way too weird to be simple programming error. Lo and behold, after I had recompiled the whole shebang with 3.4, the debug build worked like a charm. Aaaaaargh!

I went through all this with my transitional tool set – as usual, I used vim to do most of the source editing since the make integration and alternate files script are quite useful. Also, I have a number of macros for easier integration with Perforce set up.

While I’m quite happy with source code editing and build integration in my Linux environment, I have yet to find a debugging solution that really satisfies me. I’m not all that happy to admit it, but I miss Microsoft’s VisualStudio debugger. I know how to do most of the things I can do in VisualStudio in gdb, but some of them take me a lot longer. One of the features I miss most is support for persistent breakpoints – I have a pretty iterative working style, and so with the XEmacs/gdb setup, there’s a number of annoyances that I run into a lot – I recompile the program and have to manually reload it into gdb, or I quit gdb when I meant to kill the debuggee, and then have to reset all the break points. Also, displaying data is just a lot nicer in the VisualStudio UI than in GDB – ddd is supposed to fix that, but I have yet to persuade it to play nicely with my ion workspace before I feel comfortable with it.

Granted, I’m just a lowly acolyte in the churches of Emacs and GDB (before today, I didn’t know that I could print someString.c_str() and always dug my way through output like

(gdb) p tmp
$1 = {static npos = 4294967295,
  _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::__mt_alloc<char>> = {
        static _S_once = <optimized out>, static _S_init = <optimized out>,
        static _S_options = <optimized out>,
        static _S_binmap = <optimized out>,
        static _S_thread_freelist_first = <optimized out>,
        static _S_thread_freelist_mutex = <optimized out>,
        static _S_thread_key = <optimized out>,
        static _S_bin = <optimized out>,
        static _S_bin_size = <optimized out>}, <No data fields>},
    _M_p = 0x804d484 ' ' <repeats 99 times>, "2\n"}}

to inspect an STL string), but I still think the learning curve is a bit steep there and a nice integrated debugger would be really useful. Of course, I should probably not get my hopes too high for C/C++, given that all the innovation in IDEs seems to happen elsewhere. For some depression, have a look at these screen shots of Apple’s Dylan development tools, circa 1995 (via Sex, Drugs, Compiler Construction).

This week’s Economist has an article on the US-driven introduction of RFID passports. If you don’t subscribe to the Economist, Ian Grigg’s FC has a c&p of the article and some comments.

My favourite excerpt:

The third, and scariest problem, however, is one that is deliberately built
into the technology, rather than being an accident of its present
inefficiency. This is the remote-readability of the chip, combined with the
lack of encryption of the data held on it. Passport chips are deliberately
designed for clandestine remote reading. The ICAO specification refers quite
openly to the idea of a “walk-through” inspection with the person concerned
“possibly being unaware of the operation”. The lack of encryption is also
deliberate-both to promote international interoperability and to encourage
airlines, hotels and banks to join in. Big Brother, then, really will be
watching you. And others, too, may be tempted to set up clandestine
“walk-through inspections where the person is possibly unaware of the
operation”. Criminals will have a useful tool for identity theft. Terrorists
will be able to know the nationality of those they attack.

So, yes, RFID passports might make me more secure, by reducing risk of being mistaken for an American and consequently being blown up. It’s also encouraging to see these concerns voiced outside the blogosphere and the usual suspects’ circles by the usually quite sober Economist.

If I ever become a seasoned software developer, I want to be just like jwz, destroying other people’s dreams.

Some truth in the comments, too -

i’ve been listening to a lot of grumblings lately about how although nobody really likes MS exchange, it does a lot of things in one place that really SHOULD be done in one place that there isn’t a good alternative for.

Obviously, I disagree – EMACS has everything in one place, but then again, that’s a place that most people don’t want to go…

i am obviously not a managing asshole type, but i’d really like to see a good “free groupware system.” it could make stupid problems at work go away, which would mean i could get home sooner, which would give me more time to get back to the more serious business of getting laid.

I’m not quite sure that these expectations can be fulfilled with a piece of code – I’ve found out that software doesn’t add too much organizational value to me, since I get caught up in technical details of synching this with that and automating stuff, thereby spending more time for meta-organization than I save by organizing. Paper three-by-fives (A7, for us German-dominated people) can go a long way. If you have a system of organization, putting it into software is usually not the hard part – but if you just start “getting organized” by setting up of funky tools, you’re bound to fail (at least I did, multiple times).

Ah yes, and good luck with Hula, Nat.

43folders links to Microsoft’s 21 Rules of Thumb for software development. Rule number 12 is cool:

Ah. I wonder who their system software vendor is?

Update: EKR didn’t write this, 43folders did. Crap.

The infamous GtkFileChooser bug that I’ve been complaining about has been fixed – and only four months and seven days after it was reported, too!

On the plus side, it only took them three days to incorporate the patch once an outsider sent a patch to fix the problem.