Unfortunately, I’m sometimes unable to avoid having to use Microsoft products. Like all right-thinking people, I naturally abhor Microsoft. It’s not for their convicted-monopolist practices so much as their boneheaded corporate stupidity and incurable Not-Invented-Here syndrome and the fact that, even with their unparalleled human and financial resources, they just can’t get the simplest things right.

Case in point: MSDN. That’s the Microsoft Developer Network, by the way, the home of their half-assed documentation efforts on the web. It has often fairly been pointed out that Google is a better search engine for MSDN than MSDN’s own search engine. It’s that bad!

You can make a case that it’s a big site, and therefore text search is a complex problem. Except...text searching is a commodity technology. If Google can search the entire internet in less time than it takes MSDN to search it’s own site, something is wrong.

When—if—you find the information you require on MSDN, you then have to suffer the slow-loading pages, bogged down by a surfeit of frames and dynamic HTML kludgery for no obvious reason.

It appears that no one at Microsoft has thought to examine the impact of network latency and bandwidth restrictions on the interface. Did it perhaps not occur to them that people outside Seattle might be using it too?

Try this comparison:

But it’s not MSDN specifically that makes me cry.

It’s not the fact that “Administrator” is more than three times as long as “root” as a name for the master account.

It’s not even “PROGRA~1” or the cringeworthy “My” prefixed on the front of everything. (Seriously, have you seen the user interface for the entertainment edition of XP? “My Music”; “My Pictures”; “My TV”; hell, even “My Computer” is absurd when you work in an office on a company PC.)

No, it’s Microsoft’s programming languages, specifically their scripting languages, and their woeful shortcomings.

I’ve had a couple of DRM tasks to work on over the past few days, which necessitates IIS and either VBScript or JScript (essentially a dialect of JavaScript). VBScript is syntactically ugly and long-winded and has some peculiar expressions, so I tend to choose the JScript route where possible. It does at least look like a grown-up programming language.

Shockingly, however, neither language has support for anything as basic as retrieving the “Accept-Language” header from an HTTP request. Basically, your browser tells the server which languages you understand and in which order of preference, giving the server the option of responding in the user’s language if possible. It’s really useful, sometimes.

In PHP, Perl or Ruby, it’s a simple one-liner to find this value.

In VBScript or JScript, disgracefully, there is no such function. Why the hell not? Microsoft’s official VBScript solution (parsing the raw headers yourself) is a whopping 23 lines long! How many wheels must we reinvent to do the most basic of tasks?

I came up with a better solution. The JScript fragment below uses a regular expression to do the same thing a lot more easily. Feel free to save yourself time and use it. It could be translated to VBScript fairly easily.

function getAcceptLanguage()
{
    var sv = Request.ServerVariables("ALL_RAW");
    var rx = new RegExp("accept-language: *([a-z]{2})”, “i");
    if (rx.test(sv)) return RegExp.$1;
    else return “en";
}

Just think: the people who come up with abominations like that 23-line parser are probably the same people who write the documentation for Microsoft. That explains a lot, particularly why developing for Microsoft platforms is such a frustrating experience.