The Great Dub-Dub-Dub Debate

Pop quiz, hotshot. Which one is the superior Uniform Resource Locator?

www.fakeplasticrock.com

or

fakeplasticrock.com

This is one of those intractable problems. Global wars have been fought over so much less. In hacker circles, this is sometimes referred to as a bikeshed discussion.

That said, I do have a few bits of practical advice that I think apply unilaterally, whatever your position is:

1. Pick one or the other form and stick with it. Once the URL is out there in the wild, you need everyone to link to the same form for link juice amplification purposes, if nothing else. If half your incoming links are split between the www and non-www forms of your URL, that will hurt you a heck of lot more than picking the "wrong" prefix. It's also a bad idea to decide a few years down the road that you want to switch teams -- so choose wisely.

2. Make sure your site works with or without the leading www prefix. Regardless of your position on this critically important issue, your site should work either way. Serving up visitors who assumed you had a leading www prefix a 404 page is just plain bad internet citizenship, and borderline rude. Sure, encourage people to use the correct form of your URL but don't penalize them when they fail to respect your wishes. It's best if you implement URL rewriting rules that "fix" the error automatically and with no fuss for your visitors.

3. The www prefix is implicit and assumed outside the address bar. Even if you use it -- and many of the biggest sites on the internet still do -- nobody says the dub-dub-dub any more, and certainly you're not printing "www" on your logos and business cards and so forth.

4. Consider whether you plan to use other subdomains. If you plan to have, say, blog.* and mail.* and beta.* subdomain prefixes active on your domain, you might actually want the www as a disambiguator.

Beyond that, it's largely a matter of taste, though you could make a case that user-centered URL design should rule the day. If we're dropping the www prefix, why stop there? Why not drop the http:// protocol specifier before it, and the inevitable .com at the end, too?

For me, though, the great dub-dub-dub debate is mostly a source of amusement. Readable URLs are important, but you should be far more concerned about the content behind that URL than the URL itself. It's the kind of meaningless distraction that is parodied beautifully in the animated series Home Movies. The relevant section is right at the beginning of the episode "Everyone's Entitled to My Opinion".

Melissa: You know, Brendan, you don't have to say dubya-dubya-dubya any more.

Brendan: What? Why?

Melissa: You can just say the website name without the dubya-dubya-dubya.

Brendan: No, no, no. That's how you type it in, Melissa. Dubya-dubya-dubya dot..

Melissa: I know that's how you type it, but you don't have to say it. If you said to me, moviewinnerorweiner dot com, I would know what you meant, without the double-u.. double-u.. double-u.

Brendan: So no w's, ever?

Melissa: OK, Brendan, for the sake of this conversation, you don't have to say dubyadubyadubya. Because I know what it is. And so does the rest of the world.

(starts at 6:48)

Brendan: dubya-dubya-dubya dot movieweinerorwinner dot com likes my stuff a lot, so they asked me to write some stuff.

Jason: you're writing a review for dubya-dubya-dubya dot movieweinerorwinner dot com?

Melissa: (shouting) You guys, you don't have to say dubya-dubya-dubya!

Brendan: But yet..

Melissa: I don't want to have this conerversation again!

Jason: What are you talking about, Melissa?

Brendan: You have to say it Melissa. You gotta say it.

Melissa: (exasperated sigh) You don't!

Brendan: You gotta say it.

Melissa: You don't, because everyone knows what it means!

Jason: How do you know it's a website?

Melissa: Because you say dot com.

Jason: Yeah, but how do you know it's dubya-dubya-dubya?

Brendan: Yeah, that's a good point!

Melissa: Because it's just one of those things that when something's around for a long enough time in society, you can just abbreviate it.

Brendan: Like what else?

Jason: Like what, like names? Names of people?

Brendan: That's what I was saying.

Melissa: (exasperated) All right, you know what? Say dubya-dubya-dubya, I don't care.

Jason: No, you know what I'm saying.

Melissa: No, forget it. You're right. In fact, don't say dubya-dubya-dubya, say "world wide web" every time you say a website.

(pause)

Jason: No, that's a total waste.

Brendan: That's a waste of time.

My point exactly.

Programmers Don't Read Books -- But You Should

One of the central themes of stackoverflow.com is that software developers no longer learn programming from books, as Joel mentioned:

Programmers seem to have stopped reading books. The market for books on programming topics is miniscule compared to the number of working programmers.

Joel expressed similar sentiments in 2004's The Shlemiel Way of Software:

But the majority of people still don't read. Or write. The majority of developers don't read books about software development, they don't read Web sites about software development, they don't even read Slashdot.

If programmers don't learn from books today, how do they learn to program? They do it the old-fashioned way: by rolling up their sleeves and writing code -- while harnessing the collective wisdom of the internet in a second window. The internet has rendered programming books obsolete. It's faster, more efficient, and just plain smarter to get your programming information online. I believe Doug McCune's experience, which he aptly describes as Why I Don't Read Books, is fairly typical.

I lay part of the blame squarely at the feet of the technical book publishing industry:

1. Most programming books suck. The barrier to being a book author, as near as I can tell, is virtually nonexistent. The signal to noise of book publishing is arguably not a heck of a lot better than what you'll find on the wilds of the internet. Of the hundreds of programming books released every year, perhaps two are three are truly worth the time investment.

2. Programming books sold by weight, not by volume. There seems to be an inverse relationship between the size of a programming book and its quality. The bigger the book, somehow, the less useful information it will contain. What is the point of these giant wanna-be reference tomes? How do you find anything in it, much less lift the damn things?

3. Quick-fix programming books oriented towards novices. I have nothing against novices entering the programming field. But I continue to believe the "Learn [Insert Language Here] in 24 hours!" variety of books are doing our profession a disservice. The monomaniacal focus on right now and the fastest, easiest possible way to do things leads beginners down the wrong path -- or as I like to call it, "PHP". I kid! I kid!

4. Programming book pornography. The idea that having a pile of thick, important-looking programming books sitting on your shelf, largely unread, will somehow make you a better programmer. As David Poole once related to me in email, "I'd never get to do that in real life" seems to be the theme of the programming book porn pile. This is why I considered, and rejected, buying Knuth's Art of Computer Programming. Try to purchase practical books you'll actually read, and more importantly, put into action.

As an author, I'm guilty, too. I co-wrote a programming book, and I still don't think you should buy it. I don't mean that in an ironic-trucker-hat, reverse-psychology way. I mean it quite literally. It's not a bad book by any means. I have the utmost respect for my esteemed co-authors. But the same information would be far more accessible on the web. Trapping it inside a dead tree book is ultimately a waste of effort.

The internet has certainly accelerated the demise of programming books, but there is some evidence that, even pre-internet, programmers didn't read all that many programming books. I was quite surprised to encounter the following passage in Code Complete:

Pat yourself on the back for reading this book. You're already learning more than most people in the software industry because one book is more than most programmers read each year (DeMarco and Lister 1999). A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you'll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.

I believe the same text is present in the original 1993 edition of Code Complete, but I no longer have a copy to verify that. A little searching uncovered the passage Steve McConnell is referencing in DeMarco and Lister's Peopleware:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

It pains me greatly to read the reddit comments and learn that people are interpreting the stackoverflow.com mission statement as a repudiation of programming books. As ambivalent as I am about the current programming book market, I love programming books! This very blog was founded on the concept of my recommended developer reading list. Many of my blog posts are my feeble attempts to explain key concepts outlined long ago in classic programming books.

How to reconcile this seemingly contradictory statement, the love and hate dynamic? You see, there are programming books, and there are programming books.

The best programming books are timeless. They transcend choice of language, IDE, or platform. They do not explain how, but why. If you feel compelled to clean house on your bookshelf every five years, trust me on this, you're buying the wrong programming books.

I wouldn't trade my programming bookshelf for anything. I refer to it all the time. In fact, I referred to it twice while composing this very post.

I won't belabor my recommended reading list, as I've kept it proudly the same for years.

(Update: Tim Spalding kindly set up a LibraryThing account on my behalf -- and members have already documented and entered every book pictured on these shelves. Impressive, and quite cool!)

But I do have this call to arms: my top five programming books every working programmer should own -- and read. These seminal books are richly practical reads, year after year, no matter what kind of programming I'm doing. They reward repeated readings, offering deeper and more penetrating insights into software engineering every time I return to them, armed with a few more years of experience under my belt. If you haven't read these books, what are you waiting for?

Code Complete 2	Don't Make Me Think	Peopleware	Pragmatic Programmer	Facts and Fallacies

It is my greatest intention to make stackoverflow.com highly complementary to these sorts of timeless, classic programming books. It is in no way, shape, or form meant as a replacement for them.

On the other hand, if you're the unfortunate author of Perl for Dummies, then watch your back, because we're definitely gunning for you.

Building Your Own Home Theater PC

I've kept a PC in my living room for the past three years as my primary home theater interface, and I heartily recommend it. It's shocking how cheap and easy it is to build a home theater PC these days.

I've been pondering an upgrade to my creaky old home theater PC, and rave reviews of the new integrated AMD platform at Tech Report, Silent PC Review, and Tom's Hardware finally pushed me over the edge.

I didn't buy the PSU because I already have that particular model, but I bought everything else on this list for a grand total of less than 250 bucks. (You can save a bit on the power supply, but I don't recommend it, particularly if you plan to leave your HTPC running 24/7. Efficient power supplies not only save you money on electricity in the long run, but also tend to be of generally higher quality, and quieter to boot.)

The new AMD 780G platform is striking in its simplicity. Just pop in the RAM and the low-power Athlon X2 CPU and you have an (almost) complete ultra low-power home theater PC. Just check out the awesome array of rear panel connections:

We have the expected stuff (4x USB, gigabit ethernet), but the exciting part is DVI, VGA, and HDMI video out! Not to mention optical digital out for beautiful, pristine digital audio direct to your receiver. Those are the key connections for a home theater PC. We even have an eSATA port and firewire thrown in, which is always nice.

I simply dropped the new motherboard and DVD in my existing transparent acrylic Micro-ATX PC case, replacing the old stuff. (If you're thinking of going this route, I can recommend the Antec Minuet Micro-ATX case for $100, which conveniently comes with an efficient power supply, too -- but be aware of the half-height expansion slots.)

I kept my existing hard drives (a small 2.5" boot drive for low noise / power consumption, and giant capacity 3.5" drives for long-term storage and recording), and my Hauppauge PVR-150 dual analog PCI tuner card, which I love to death.

For the longest time, integrated graphics was synonymous with craptacular graphics. That's not the case for this new AMD 780g chipset. The integrated graphics are fully DirectX 10 compliant, comparable to the latest entry-level discrete video cards. Gaming isn't our goal, though this would be perfectly adequate for many games. More importantly for a HTPC build, the integrated graphics support the full suite of H.264 and WMV video playback acceleration.

I know a WEI graphics score of 3.5 doesn't sound like much, but brother, let me tell you -- this is light years ahead of anything else on the market at this power consumption point.

Update: I had a hardware failure of my own causing (don't ask) and I needed to replace this motherboard. Fortunately, there is a new version of this motherboard with 128 MB of dedicated "sideport" DDR3 graphics memory on board. With the addition of dedicated video memory the WEI graphics score went from 3.5 / 3.6 to 4.0 / 4.0!

My old Pentium-M single core struggled to play back 1080p videos. The Athlon X2 4050e CPU I chose is one of AMD's low power dual core models, far from top of the line. The testers at SilentPCReview found any modern dual core chip is more than enough for the most strenuous of video playback tasks:

Gradually underclocking the CPU, we found that the Blu Ray disc began to stutter at about 1.1Ghz, while audio glitches were detected in the WVC1 clip at 1.4Ghz. 1.5Ghz was the lowest clock speed that would smoothly play back all our clips. This was a fantastic result as the lowest clocked X2 on the market is 2.0 Ghz.

AMD is a better choice for a home theater PC because their idle voltage and multiplier throttling -- the marketing term is "Cool n' Quiet" -- is outstanding. (I'm also glad to have the opportunity to support AMD because I'm desperately afraid of a world where Intel is the only CPU vendor. And you should be too.) This variant of the Athlon 64 X2 chip is so new that CPU-Z doesn't quite recognize it by name. But as you can see, at idle, it clocks down to a miserly 1 GHz and reduces its power consumption to barely over one volt.

My old highly optimized HTPC build consumed just under 80 watts at idle, up from around 65 before I began upgrading it to make it more Vista friendly. Guess how much this new HTPC platform build, which is more than twice as powerful, consumes at idle? Let's whip out our handy dandy kill-a-watt and find out:

FORTY. SIX. WATTS.

That is flippin' amazing. We're talking about a powerful modern PC here, with quite a bit of additional hardware you wouldn't find in most PCs, including a dual TV tuner PCI card and three hard drives. Granted two of those drives are in sleep mode most of the time, but still. 46 watts -- twice the power at almost half the energy consumption! Incredible! Silence and efficiency were nowhere near this easy three or four years ago.

Needless to say, I'm pretty excited about this particular $250 upgrade, and I can sell my old parts to underwrite it.

On the software front, as I mentioned at the top, I've been a fan of Windows Media Center since the first version; it's one of the best products to come out of Redmond in years, and the version of Media Center bundled with Vista (well, Ultimate and Home Premium, anyway) is the best yet. With a hardware setup this compelling, I'm sure you'll have no problem at all mating it with your favorite HTPC software.

If you do end up running Windows and connecting your HTPC to a DVI or HDMI capable television, beware. Getting an exact, pixel-for-pixel connection between your HTPC and your TV isn't easy. For example, I had trouble getting the ATI Catalyst graphics driver to accept 852x480, the standard resolution of our old plasma EDTV. Sure 800x600 worked fine, but the aspect ratio was totally off. That's where PowerStrip comes in.

PowerStrip will let you achieve that ideal pixel-for-pixel perfect connection between your graphics card and your television. I selected the built in EDTV preset as a custom resolution, and all was well. PowerStrip is the go-to utility for tweaking home theater display output.

We use our home theater PC every day. It's silent, draws very little power, and it's small enough to tuck away cleanly in our living room decor. It plays anything through a slick 10-foot UI, and offers unrestricted access to the web at any time. Putting a great one together today is almost ridiculously easy. If you haven't considered building your own home theater PC -- why not?

UPDATE: since people asked, here's a complete from-scratch build list for a home theater PC.

If you plan to use Vista Media Center, add a Vista Home Premium SP1 license for $110. I also saw that Blu-Ray internal drives (read only) are down to $130 as of the time I'm writing this.

The Problem with Software Registration

As a person who has spent a significant part of his professional life getting paid to write software, I believe it's important for me to regularly pay for software, too. Our programmer salaries don't come from magical money trees. They come from customers laying down cold, hard cash for the software we've built. That's why every month I try to put into action what I described in Support Your Favorite Small Software Vendor Day:

Check your hard drive, and I'm sure you, too, will find some bit of software written by a small software development shop, maybe even a single developer. Something you find incredibly useful. Something you rely on every day. Something you recommend without reservation to friends and peers. Something that makes using the computer that much more enjoyable. Or at least less painful.

Stop reading this post right now and buy that software. If it's not commercial software, don't let that stop you. Share the love by sending money to the person/shop/organization that created it.

As I encounter apps that I find helpful and use regularly, I go out of my way to support them by either donating, or registering and buying a license. It's just plain good karma. There's nothing more effective than voting with your wallet. As I see it, if you don't vote, you aren't entitled to have an opinion.

But here's what I find deeply troubling: often, registering software leaves me with a worse experience than not registering. Allow me to illustrate with an example.

I've been transferring our podcast files back and forth to blog.stackoverflow.com via FTP, so I reinstalled SmartFTP. Now, I've used SmartFTP quite a bit over the years, but never bothered to pay for it. They've done a great job of regularly improving and enhancing it every time I use it again. That's exactly the kind of useful, living software project I want to support.

Until I register, I'm presented with this little nag screen every time I start SmartFTP. It's mildly annoying, but tolerable -- and it prominently features a convenient "buy me" button. Hey! That's what I want to do!

I click that button and get whisked away to a website where I'm now confronted with a choice: home or professional?

Gee, I don't know. I'm conflicted. Now I have to think about what features I want, and how much I'm willing to pay for said features.

This is already starting to be kind of a drag.

I now feel like I'm being gamed. There's a name for this game, and unfortunately it's not something fun and cool like Grand Theft Auto IV -- this particular game is called capturing consumer surplus.

Let's do this. Instead of charging $220, let's ask each of our customers if they are rich or if they are poor. If they say they're rich, we'll charge them $349. If they say they're poor, we'll charge them $220.

Now how much do we make?

Notice the quantities: we're still selling the same 233 copies, but the richest 42 customers, who were all willing to spend $349 or more, are being asked to spend $349. And our profits just went up! from $43K to about $48K! NICE!

Any resemblance between this and Windows Vista Kenny Loggins edition is, I'm sure, purely coincidence. I finally decide I'm a "home" FTP user, whatever the heck that means. I suspect it's a sneaky marketing weasel synonym for "cheap bastard".

As a reward, now I get to play another game called fill out the giant order form. You've played this one before. Note that in this particular game, you can score bonus points for trying to route this form through your complex corporate payment system.

After all that, I manage to pay. It's a sort of unavoidable flat tax on effort for any form of online commerce. Eventually, I receive this in my email inbox:

Now I have three choices. None of which make a whole lot of sense on my initial reading. It looks like there's some kind of key file I'm going to need? I'll try the middle link to download it. I don't really want another executable of unknown provenance on my system. After downloading the license file, I use the help menu to install it:

Et Voil! In only sixteen fun and easy steps, I have registered this software and voted with my wallet!

But that registration is only the beginning of my problems:

• I now need to keep track of a license file.
• The license is probably tied to a particular computer, so if I reinstall the OS, or upgrade the hardware, that license might break.
• If I lose my license, I need to remember my login credentials on the vendor's website to retrieve them.
• My license is only valid for one year. When that year is up, I need to go through these motions and re-license the software yet again.

Now-- and here's the kicker-- multiply all this licensing pain by the number of applications and people in your organization.

Even for a solo user like me, it's bad. I have apps I've registered and paid for that I somehow never got license keys for, such as WinRAR. I have apps that I simply don't use because I'm too lazy to re-register them on my new install, such as EditPad Pro. I've long since lost track of what versions of which apps I have valid registrations for. You can imagine the kind of fun that awaits me at the end of any new system build, a virtual jamboree of re-registrations.

Now let's compare that with the process of "registering" the open source FTP tool FileZilla:

1. Download FileZilla
2. Donate $36.95 to the project

Oh, and step three? There is no step three! I never have to think about registration, licensing, or any of that other crap again. Ever!

There's no doubt that SmartFTP is the superior FTP client. I'm more than happy to register and reward them for their years of development work. But in the future, I think I'll be voting with my wallet for the registration process that makes my life easier, not harder.

Behold WordPress, Destroyer of CPUs

Lately I've been delving into the WordPress ecosystem, as it seems to be the most popular blogging platform around at the moment. I've set up two blogs with it so far. In the process, I've gotten quite comfortable with the setup, interface, and overall operation of WordPress.

1. blog.stackoverflow.com
2. www.fakeplasticrock.com

I've been thoroughly impressed with the community around WordPress, and the software itself is remarkably polished. That's not to say that I haven't run into a few egregious bugs in the 2.5 release, but on the whole, the experience has been good bordering on pleasant.

Or at least it was, until I noticed how much CPU time the PHP FastCGI process was using for modest little old blog.stackoverflow.com.

For context, this is running on a Windows Web Server 2008 virtual machine with a single core of a 2.13 GHz Xeon 3210 entirely dedicated to it.

This is an incredibly scary result; blog.stackoverflow.com is getting, at best, a moderate trickle of incoming traffic. It's barely linked anywhere! With that kind of CPU load level, this site would fall over instantaneously if it got remotely popular, or God forbid, anywhere near the front page of a social bookmarking website.

For a bare-bones blog which is doing approximately nothing, this is a completely unacceptable result. It's appalling.

As evidence of what a systemic problem this is, there's an entire cottage industry built around shoehorning better caching behavior into WordPress. Take your pick: WP-Cache, WP-Super-Cache, or Bad Behavior. The caching add-ins don't work very well under IIS because they assume they're running on a *NIX platform, but they can be coerced into working.

Does it work? Does it ever. Here's what CPU usage looks like with basic WP-Cache type functionality enabled:

I'm not alone; just do a web search on WordPress CPU usage or WordPress Digg Effect and you'll find page after page of horror stories, most (all?) of which are solved by the swift and judicious application of the WP-Cache plugins.

It's not like this a new issue. Personally, I think it's absolutely irresponsible that WP-Cache like functionality isn't already built into WordPress. I would not even consider deploying WordPress anywhere without it. And yet, according to a recent podcast, Matt Mullenweg dismisses it out of hand and hand-wavingly alludes to vague TechCrunch server reconfigurations.

A default WordPress install will query the database twenty times every time you refresh the page, even if not one single element on that page has changed. Doesn't that strike you as a bad idea? Maybe even, dare I say it, sloppy programming?

I understand that users may have umpteen thousand WordPress plugins installed, all of which demand to change on every page load. Yes, the easiest path, the path of least resistance, is to mindlessly query the database every time you're building a page. But I cannot accept that a default, bare-bones WordPress install hasn't the first clue how to cache and avoid expensive, redundant trips to the database.

It's frustrating, because caching is a completely solved problem in other programming communities. For example, the .NET framework has had page output caching and page fragment output caching baked into ASP.NET for years.

I sure am glad I started this blog in Movable Type way back in 2004. Their classic static rendering blog engine approach may be derided today, but I shudder to think of the number of times the Coding Horror webserver would have been completely incapacitated over the years by the naive -- no, that's too tame -- brainlessly stupid dynamic rendering approach WordPress uses.

What I just don't understand is why, after all these years, and all these documented problems, WordPress hasn't folded WP-Cache into the core. If you're ever planning to have traffic of any size on a WordPress blog, consider yourselves warned.

Update: Matt Mullenweg kindly responded to this post and offered his recommended MySQL configuration optimizations. I definitely agree that the Query Cache is extremely important to performance, and for some reason it defaulted to off (zero size) on my installation. You may also want to look into innotop and mysqlreport to ensure that all your MySQL caches are functioning at appropriate levels. Also, thanks to a few commenters for letting me know that one of this year's Google Summer of Code projects is integrating caching into the core WordPress code. It is badly needed.

Everything I Needed to Know About Programming I Learned from BASIC

Edsger Dijkstra had this to say about Beginner's All Purpose Symbolic Instruction Code:

It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration.

I'm sure he was exaggerating here for effect; as much as I admire his 1972 "The Humble Programmer" paper, it's hard to square that humility with the idea that choosing the wrong programming language will damage the programmer's mind. Although computer languages continue to evolve, the largest hurdle I see isn't any particular choice of language, but the fact that programmers can write FORTRAN in any language. To quote Pogo, we have met the enemy, and he is us.

Dismissing BASIC does seem rather elitist. Like many programmers of a certain age, I grew up with BASIC.

I mentioned in an earlier post the curious collision of early console gaming and programming that was the Atari 2600 BASIC Programming cartridge. I had to see this for myself, so I bought a copy on eBay.

I also bought a set of the Atari 2600 keypad controllers. The overlays come with the cartridge, and the controllers mate together to make a primitive sort of keyboard. (Also, if you were wondering what kinds of things I do with my ad revenue, buying crap like this is a big part of it, sadly.)

Surprisingly, the manual isn't available anywhere online, so I scanned it in myself. Take a look. It's hilarious. There is a transcribed HTML version of the manual, but it's much less fun to read without the pictures and diagrams.

I booted up a copy of the Basic Programming ROM in the Stella Atari 2600 emulator, then followed along with the manual and wrote a little BASIC program.

You'll notice that all the other screenshots of Atari 2600 Basic Programming on the web are essentially blank. That's probably because I'm the only person crazy enough to actually try programming in this thing. It may look painful, but you have no idea until you've tried to work with this funky "IDE". It's hilariously bad. I could barely stop laughing while punching away at my virtual keypads. But I have to confess, after writing my first "program", I got that same visceral little thrill of bending the machine to my will that I've always gotten.

The package I got from eBay included a few hand-written programming notes that I assume are from the 1980s.

Isn't that what BASIC -- even this horribly crippled, elephant man Atari 2600 version of BASIC -- is all about? Discovering fundamental programming concepts?

Of course, if you were at all interested in computers, you wouldn't bother programming on a dinky Atari 2600. There were much better options for gaming and programming in the form of home computers. And for the longest time, every home computer you could buy had BASIC burned into the ROM. Whether it was the Apple //, Commodore 64, or the Atari 800, you'd boot up to be greeted by a BASIC prompt. It became the native language of the hobbyist programmer.

Even the IBM PC had BASICA, GW-BASIC and finally QBasic, which was phased out with Windows 2000.

It's true that if you wanted to do anything remotely cutting-edge with those old 8-bit Apple, Commodore and Atari home computers, you had to pretty much learn assembly language. I don't recall any compiled languages on the scene until the IBM PC and DOS era, primarily Turbo Pascal. Compiled languages were esoteric and expensive until the great democratization of Turbo Pascal at its low, low price point of $49.99.*

Even if you lacked the programming skills to become the next David Crane or Will Wright, there were still a lot of interesting games and programs you could still write in good old BASIC. Certainly more than enough to figure out if you enjoyed programming, and if you had any talent. The Creative Computing compilations were like programming bibles to us.

For a long, long time, if you were interested in computers at all, you programmed in BASIC. It was as unavoidable and inevitable as the air you breathed. Every time you booted up, there was that command prompt blinking away at you. Why not type in some BASIC commands and see what happens? And then the sense of wonder, of possibility, of being able to unlock the infinitely malleable universe inside your computer. Thus the careers of millions of programmers were launched.

BASIC didn't mutilate the mind, as Dijkstra claimed. If anything, BASIC opened the minds of millions of young programmers. It was perhaps the earliest test to determine whether you were a programming sheep or a non-programming goat. Not all will be good, of course, but some inevitably will go on to be great.

Whether we're still programming in it or not, the spirit of BASIC lives on in all of us.

* as an aside, you may notice that Anders Hejlsberg was the primary author of Turbo Pascal and later Delphi; he's now a Technical Fellow at Microsoft and the chief designer of the C# language. That's a big reason why so many longtime geeks, such as myself, are so gung-ho about .NET.

Should All Developers Have Manycore CPUs?

Dual core CPUs are effectively standard today, and for good reason -- there are substantial, demonstrable performance improvements to be gained from having a second CPU on standby to fulfill requests that the first CPU is too busy to handle. If nothing else, dual-core CPUs protect you from badly written software; if a crashed program consumes all possible CPU time, all it can get is 50% of your CPU. There's still another CPU available to ensure that the operating system can let you kill CrashyApp 5.80 SP1 Enterprise Edition in a reasonable fashion. It's the buddy system in silicon form.

My previous post on upgrading the CPU in your PC was more controversial than I intended. Here's what I wrote:

In my opinion, quad-core CPUs are still a waste of electricity unless you're putting them in a server. Four cores on the desktop is great for bragging rights and mathematical superiority (yep, 4 > 2), but those four cores provide almost no benchmarkable improvement in the type of applications most people use. Including software development tools.

It's unfortunate, because this statement overshadowed the rest of the post. All I wanted to do here is encourage people to make an informed decision in selecting a CPU. Really, pick any CPU you want; the important part of that post is being unafraid to upgrade your PC. Insofar as the above paragraph distracted readers from that goal, I apologize.

However, I do have strong feelings on this topic. All too often I see users seduced by Intel's marketing department, blindly assuming that if two CPU cores is faster than one CPU core, then, well.. four, eight, or sixteen must be insanely fast! And out comes their wallet. I fear that many users fall prey to marketing weasels and end up paying a premium for performance that, for them, will never materialize. It's like the bad old days of the Pentium 4 again, except for absurd megahertz clock speeds, substitute an absurd number of CPU cores.

I want people to understand that there are only a handful of applications that can truly benefit from more than 2 CPU cores, and they tend to cluster tightly around certain specialized areas. To me, it's all about the benchmark data, and the benchmarks just don't show any compelling reason to go quad-core unless you regularly do one of the following:

• "rip" or encode video
• render 3D scenes professionally
• run scientific simulations

If you frequently do any of the above, there's no question that a quad-core (or octa-core) is the right choice. But this is merely my recommendation based on the benchmark data, not iron-clad fact. It's your money. Spend it how you like. All I'm proposing is that you spend it knowledgably.

Ah, but then there's the multitasking argument. I implored commenters who felt strongly about the benefits of quad-core to point me to multitasking benchmarks that showed a profound difference in performance between 2 and more-than-2 CPU cores. It's curious. The web is awash in zillions of hardware review websites, yet you can barely find any multitasking benchmarks on any of them. I think it's because the amount of multitasking required to seriously load more than two CPU cores borders on the absurd, as Anand points out:

When we were trying to think up new multitasking benchmarks to truly stress Kentsfield and Quad FX [quad-core] platforms we kept running into these interesting but fairly out-there scenarios that did a great job of stressing our test beds, but a terrible job and making a case for how you could use quad-core today.

What you will find, however, is this benchmarking refrain repeated again and again:

Like most of the desktop applications out there today, including its component apps, WorldBench doesn't gain much from more than two CPU cores.

That said, I think I made a mistake in my original statement. Software developers aren't typical users. Indeed, you can make a reasonable case that software developers are almost by definition edge conditions and thus they should seek out many-core CPUs, as Kevin said in the comments:

How would you suggest developers write applications (this is what we are, and what we do, right?) that can actually leverage 4, 8, etc... CPU cores if we are running solo or dual core systems? I put this right up there with having multiple monitors. Developers need them, and not just to improve productivity, but because they won't under stand just how badly their application runs across multiple monitors unless they actually use it. The same is true with multi-core CPUs.

I have two answers to this. One of them you probably won't like.

Let's start with the first one. I absolutely agree that it is important for software developers to consider multi-core software development, and owning one on their desktop is a prerequisite. I originally wrote about this way, way back in 2004 in Threading, Concurrency, and the Most Powerful Psychokinetic Explosive in the Universe. In fact, two of the people I quoted in that old article -- true leaders in the field of concurrent programming -- both posted direct responses to my article yesterday, and they deserve a response.

Rick Brewster, of the seriously amazing Paint.NET project, had this to say in a comment:

Huh? Paint.NET, for one, shows large gains on quad-core versus dual-core systems. There's even a benchmark. I'd say that qualifies as "applications most people use."

He's absolutely right. A quad-core Q6700 @ 2.66 GHz trounces my dual-core E8500 @ 4.0 GHz on this benchmark, to the tune of 26 seconds vs. 31 seconds. But with all due respect to Rick -- and seriously, I absolutely adore Paint.NET and his multithreading code is incredible -- I feel this benchmark tests specialized (and highly parallelizable) filters more than core functionality. There's a long history of Photoshop benchmarking along the same lines; it's the 3D rendering case minus one dimension. If you spend a significant part of your day in Photoshop, you should absolutely pick the platform that runs it fastest.

But we're developers, not designers. We spend all our time talking to compilers and interpreters and editors of various sorts. Herb Sutter posted an entire blog entry clarifying that, indeed, software development tools do take advantage of quad-core CPUs:

You must not be using the right tools. :-) For example, here are three I'm familiar with:

1. Visual C++ 2008's /MP flag tells the compiler to compile files in the same project in parallel.
2. Since Visual Studio 2005 we've supported parallel project builds in Batch Build mode
3. Excel 2007 does parallel recalculation. Assuming the spreadsheet is large and doesn't just contain sequential dependencies between cells, it usually scales linearly up to at least 8 cores.

Herb is an industry expert on concurrent programming and general C++ guru, and of course he's right on all three counts. I had completely forgotten about C++ compilation, or maybe it's more fair to say I blocked it out. What do you expect from a guy with a BASIC lineage? Compilation time is a huge productivity drain for C++ developers working on large projects. Compilation time using gcc and time make -j<# of cores + 1> is the granddaddy of all multi-core programmer benchmarks. Here's a representative result for compiling the LAME 3.97 source:

The absolute numbers seem kind of small, but the percentages are incredibly compelling, particularly as you add up the number of times you compile every day. If you're a C++ developer, you need a quad-core CPU yesterday. Demand it.

But what about us managed code developers, with our lack of pointers and explicit memory allocations? Herb mentioned the parallel project builds setting in Visual Studio 2008; it's under Tools, Options, Projects and Solutions, Build and Run.

As promised, it's defaulting to the number of cores I have in my PC -- two. I downloaded the very largest .NET project I could think of off the top of my head, SharpDevelop. The solution is satisfyingly huge; it contains 60 projects. I compiled it a few times in Visual Studio 2008, but task manager wasn't showing much use of even my measly little two cores:

I did see a few peaks above 50%, but it's an awfully tepid result compared to the make -j4 one. I see nothing here that indicates any kind of possible managed code compilation time performance improvement from moving to more than 2 cores. I'm sort of curious if Java compilers (or other .NET-like language compilers) do a better job of this.

Getting back to Kevin's question: yes, if you are a software developer writing a desktop application that has something remotely parallelizable in it, you should have whatever number of CPU cores on the desktop you need to test and debug your code. I suggest starting with a goal of scaling well to two cores, as that appears to be the most challenging part of the journey. Beyond that, good luck and godspeed, because everything I've ever read on the topic of writing scalable, concurrent software goes out of its way to explain in excruciating detail how hellishly difficult this kind of code is to write.

Here's the second part of the answer I promised you earlier. The one you might not like. Most developers aren't writing desktop applications today. They're writing web applications. Many of them may be writing in scripting languages that aren't compiled, but interpreted, like Ruby or Python or PHP. Heck, they're probably not even threaded. And yet this code somehow achieves massive levels of concurrency, scales to huge workloads, and drives some of the largest websites on the internet. All that, without thinking one iota about concurrency, threading, or reentrancy. It's sort of magical, if you think about it.

So in the sense that mainstream developers are modelling server workloads on their desktops, I agree, they do probably need as many cores as they can get.

Building a PC, Part V: Upgrading

Last summer I posted a four part series on building your own PC:

• Building a PC, Part I: Minimal boot
• Building a PC, Part II: Burn in
• Building a PC, Part III: Overclocking
• Building a PC, Part IV: Now It's Your Turn

My personal system is basically identical to that build, though it predates it by about six months. The only significant difference is the substitution of the Core 2 Duo E6600 CPU.

In my opinion, quad-core CPUs are still a waste of electricity unless you're putting them in a server. Four cores on the desktop is great for bragging rights and mathematical superiority (yep, 4 > 2), but those four cores provide almost no benchmarkable improvement in the type of applications most people use. Including software development tools. (Update: This paragraph was more controversial than intended. See Should All Developers Have Manycore CPUs? for a clarification.)

My original advice stands: for the vast majority of users, the fastest possible dual-core CPU remains the best choice. I overclocked my E6600 CPU from 2.4 Ghz to 3.2 Ghz, instantly increasing the value of the processor by about 800 bucks.

Beyond overclocking, the economy of building your own PC also lies in upgrading it in pieces and parts to keep it up to date. Once you've taught yourself to build a PC, swapping parts out is easy. That's an option you almost never have on laptops, and rarely on commercial desktops.

It's been almost a year and a half since I made any significant change to my PC build. That's an eternity in computer dog years. I was developing a serious itch to upgrade something -- anything -- on my PC. I did a bit of research, and I was surprised to find that the P965 chipset on my Asus P5B Deluxe motherboard supports the latest and greatest Intel CPUs. This is a pleasant surprise indeed; Intel and AMD change the pinouts and sockets of their CPUs quite regularly. A simple CPU upgrade, more often than not, forces a complete motherboard and memory upgrade. But not in this case!

So here's what I did:

1. flash the BIOS* on my motherboard to the latest version, which supports the newest CPUs
2. remove the old and busted CPU (Core 2 Duo E6600, 2.4 GHz, 4 MB L2)
3. drop in the new hotness CPU (Core 2 Duo E8500, 3.16 GHz, 6 MB L2)
4. Manually adjust FSB speed, memory voltage and CPU voltage

This chip is an outstanding overclocker. It's almost a no-brainer. The tubes are full of documented cases of this chip reaching 4.5 GHz and sometimes higher. I was fairly content with my effortless 4 GHz overclock:

If you're wondering why CPU-Z says this is a 2520 MHz CPU instead of the 4000 MHz you'd expect, that's because the CPU is idle. All modern CPUs clock down at idle to reduce power draw. If you run something CPU intensive, you'll see the CPU speed dynamically change in CPU-Z, as illustrated by this animated GIF:

This power savings is achieved by dropping the CPU multiplier from its default of 9.5 down to 6.0. If we do a little math, it's easy to infer the relationship between FSB (front side bus), CPU multiplier, and actual CPU speed:

Overclocking the CPU is simple if you can stumble your way through a few basic BIOS screens. The default voltage on this E8500 is 1.128 volts. By juicing the CPU voltage up to 1.36 volts, and setting the front side bus (FSB) to 420 MHz, we can hit the magical 4 GHz number. All we need to do is a little unit testingburn-in torture testing, and we can confirm that it's stable.

But you might wonder -- does this overclocking stuff really justify the hassle? Is going from 3.0 GHz to 4.0 GHz really worth it in terms of actual performance and not just bragging rights?

I'm glad you asked!

I clocked my E8500 to 3.0 GHz / 315 FSB and 4.0 GHz / 420 FSB and ran a few quick SunSpider JavaScript benchmarks. You may remember this great little benchmark from The Great Browser JavaScript Showdown. Here's what I found:

And the overall benchmark result in table form:

That's a consistent 19% performance improvement in an interpreted browser language for a 33% increase in raw CPU clock speed. Not too shabby. It's actually more than I expected. The real speed difference between an E6600 and E8500 would be (slightly) greater than the pure clock speed indicates, due to the architectural improvements and larger L2 cache in the E8500. There also might be other languages and apps that scale more linearly with that 33% CPU clock speed increase.

Compare the result of going from 3 GHz to 4 GHz with adding another two cores, which would produce exactly zero improvement in your JavaScript benchmarks. Most apps are barely multithreaded, much less capable of taking advantage of all four cores. Having four CPU cores won't help you much when they're all poking along at a leisurely 2 GHz.

So if you followed our original PC build plan, or if you're planning to build your own PC -- don't forget to factor upgrading into your system's lifespan! These builds are eminently upgradeable. Sometimes you'll get lucky and have knockout upgrade options like the E8500: a 4 GHz (almost) guaranteed drop-in CPU replacement for under 300 bucks.

* I am simplifying a little because I don't want to scare anyone. In the interests of full disclosure, here's the story. The ASUS Windows x64 BIOS flash program crashed while updating the motherboard BIOS. I can't quite describe the chill that went down my spine as I watched this happen. Any failure during a BIOS flash is irrevocable and permanent, the very definition of "bricking". To be fair, this is literally the first time I've ever bricked anything in at least 10 years of regular yearly BIOS flashing. I had to buy another motherboard and initiate a RMA on my original, newly BIOS-free motherboard. Let this be a lesson to you, kids: don't trust Windows software developers! Always update the BIOS from a boot CD or from within the BIOS itself using a USB key!

Introducing Stackoverflow.com

A little over a month ago, I announced that I was quitting my job. But there was also something else I didn't fully announce.

But I refuse to become a full-time blogger. I think that's a cop-out. If I look at the people I respect most in the industry, the people I view as role models-- Paul Graham, Joel Spolsky, Steve Yegge, Eric Sink, Rich Skrenta, Marc Andreesen, Wil Shipley, Douglas Crockford, Scott Guthrie -- they all have one thing in common. They're not just excellent writers and communicators. They build stuff, too. The world has enough vapid commentary blogs. I want to build stuff-- and talk about it. I have a little micro-ISV startup opportunity I'll be working on, a web property I'm building out with one of the above people. I'm not ready to announce the details yet, but when I do, you'll read about it here.

The "building stuff", as you helped us determine, is stackoverflow.com. It's a small company Joel Spolsky and I are founding together.

If you've been reading my blog for a while, you might find this pairing strange. It's true that I've been critical of Joel in the past. And it is sort of funny that I own the number one image search result and a top 10 search result for Joel Spolsky. Good thing Joel has a sense of humor.

Occasionally I'll meet readers, or get emails from readers, who tell me that they enjoy my blog... and oh-by-the-way they strongly disagree with a few things I've said. Their phrasing clearly implies that they think there's something wrong with this. Well, there isn't. I'm here to tell you that occasional disagreement is healthy and normal. If you agree with everything I write here, why would you bother reading? At that point, we're the same person. I distrust people who agree with me all the time. I want someone to push back and encourage me to question my assumptions.

I admire what Joel has created. He was one of the earliest programming bloggers, and certainly one of the first I found that helped me realize the kind of positive influence writing could have on my fellow programmers. He is very much living the dream: he founded a company with the express intent of not cashing out with VC money, but creating a sustainible place where programmers can have fun while programming useful stuff. It's an honor to have the opportunity to work closely with Joel, and to combine the collective power of our two communities.

So what is stackoverflow?

From day one, my blog has been about putting helpful information out into the world. I never had any particular aspirations for this blog to become what it is today; I'm humbled and gratified by its amazing success. It has quite literally changed my life. Blogs are fantastic resources, but as much as I might encourage my fellow programmers to blog, not everyone has the time or inclination to start a blog. There's far too much great programming information trapped in forums, buried in online help, or hidden away in books that nobody buys any more. We'd like to unlock all that. Let's create something that makes it easy to participate, and put it online in a form that is trivially easy to find.

Are you familiar with the movie pitch formula?

Stackoverflow is sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit. It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

Of course, there's more to it than that. Joel and I are recording our weekly calls and releasing them as podcasts. Listen to us describe our vision for stackoverflow in our own words -- just head over to stackoverflow.com to download the first 46 minute episode. We're even taking questions, if you submit them in the form of audio recordings.

Your Session Has Timed Out

How many times have you returned to your web browser to be greeted by this unpleasant little notification:

Your session has timed out. Please sign in again.

If you're anything like me, the answer is lots. What's worse is that you're usually kicked out of whatever page context you were working in. You have to manually log in again, remember what you were doing, then navigate back to where you were and resume your work.

Most programmers look at these sort of browser session timeouts as a necessary evil -- sometimes even as a security "feature". I know my bank website zealously logs me out of its web interface if I'm idle for more than five minutes. I'm not sure either one of these reasons are particularly justifiable.

As a programmer, I understand why session expiration occurs. The HTTP protocol that the web is built on is stateless. That means every individual request your browser sends to a web server is a newborn babe, cruelly born into a world that is utterly and completely oblivious to its existence. The way modern web applications get around this is by telling the browser to send a small, unique value back to the website with each request -- this is known as a HTTP cookie. It sounds a lot tastier than it looks:

Content-type: text/html
Cookie: SessionId=5451297120

While there are privacy concerns with cookies, it is a generally accepted practice today -- at least for the first-party cookie flavors. While it is possible to maintain state without cookies, it's painful and awkward.

Every web request to that server will include its own cookie and associated session id until it expires, usually many months or even years hence. The browser definitely isn't the forgetful party here.

It's up to the server to correlate the unique session identifier sent by the browser with your individual identity, context, settings, and preferences. This is usually stored in a database of some kind, keyed by your session identifier. For performance reasons, some chunk of session information also ends up in the server's memory; there's no need to reach all the way out to the database the next twenty-six times you obsessively refresh your Facebook profile page.

Still, that doesn't explain why the web server mysteriously forgets about us. If anything, the server has all the information it needs to remember you, even if you walked away from your computer for a week. So why does the server choose to arbitrarily forget about you in an hour?

1. Performance. Consider a highly trafficked web site. If the website tried to keep sessions alive for an entire month, that could cause the session table to grow to millions of records. It's even worse if you think about it in terms of user information cached in memory; a measly few kilobytes of memory state per user doesn't sound like much, but multiplied by a few million, it absolutely is. If this data wasn't expired and dumped on some schedule, it would quickly blow up the web server.

2. Security. The magic cookie that stores your session can potentially be stolen. If that cookie never expires, you have an infinitely long vulnerability window to session hijacking. This is serious stuff, and mitigation strategies are limited. The best option, short of encrypting the entire connection from end to end via HTTPS, is to keep a tight expiration window on the session cookie, and regenerate them frequently.

That's the why of browser session timeouts from the programmer's perspective. But that doesn't make it right. Far from it.

As a user, I can say pretty unequivocally that session expiration sucks. Is it really so unreasonable to start doing something in your web browser, walk away for an hour -- maybe even for a few hours -- then come back and expect things to just work?

As programmers, I think we can do better. It is possible. I am inundated with session timeout messages every day from a variety of sources, but I've never once seen a session expiration message from gmail, for example. Here's what I suggest:

1. Create a background JavaScript process in the browser that sends regular heartbeats to the server. Regenerate a new cookie with timed expiration, say, every 5 or 10 minutes.

2. If you're worried about session hijacking -- and you really should be -- use a HTTPS protected connection. This is an absolute no-brainer for financial institutions of any kind.

I wish more developers would test their web applications for session timeout issues. Despite all rumors to the contrary, your users will not be dedicating their entire lives to using your web application in a punctual and timely manner. They have phone calls to take, meetings to go to, other websites and applications to attend to.

Is it really fair to kick users all the way out of your web application, or worse, blindly reject data they've submitted -- just because they were impudent enough to wait a few hours since their last supplication to the web server gods? In most web apps, the penance is awfully severe for such a common sin.