Computer Languages aren't Human Languages

Though I've become agnostic about the utterly meaningless non-choice between VB.NET and C#, the inherited syntax of C leaves a lot to be desired, in my opinion. And not just in the case sensitivity department. Daniel Appleman, in his excellent e-book, VB.NET or C#, Which to Choose?, concurs:

Here I risk stepping on some toes, because language syntax is very much a religious issue with many programmers. Certainly we all tend to prefer the language syntax we are familiar with, and C++ and Java programmers will certainly find a great deal that is familiar in C#.

It should also be clear from this section that the differences between the two languages in this area really are minor. Both have virtually the same functionality.

Nevertheless, on the subject of object syntax, I must give the win to VB.NET. Just look at the inheritance declarations:

public class BClass: AClass, Iint

Public Class BClass
Inherits AClass
Implements Iint

Look at the words used to control inheritance:

abstract, sealed, virtual
MustInherit, NotInheritable, Overridable, Overrides, Shadows

When it comes to looking at code and understanding what it does -- especially later on when the original developer has left and some young programmer right out of college has to figure out what it does quickly to solve some obscure bug or add a new feature, which one is going to be easier to understand? Visual Basic .NET.

Although I do agree with Appleman on this point-- void is for sci-fi geeks; nothing is for human beings-- in the big scheme of things, it's barely relevant. If the success or failure of your project hinges on the minor syntax differences between two virtually identical .NET languages, you have much deeper problems than choice of language.

Although the tradeoff between verbosity and succinctness is worth considering, there are other risks here. Computer languages, however verbose you make them, shouldn't try to become proxy versions of spoken languages. I've never worked with AppleScript before, but it fell into this trap in a big way. Here's a sample bit of AppleScript code to illustrate:

tell application "Mori"
  tell front document
    set a to first item of selection
    set b to second item of selection
    set a's note to (a reference to a's) note & (a reference to b's note)
  end tell
end tell

Looks almost like a paragraph, doesn't it? John Gruber calls AppleScript the English-Likeness Monster:

The idea was, and I suppose still is, that AppleScript's English-like facade frees you from worrying about computer-science-y jargon like classes and objects and properties and commands, and allows you to just say what you mean and have it just work.

But saying what you mean, in English, almost never "just works" and compiles successfully as AppleScript, and so to be productive you still have to understand all of the ways that AppleScript actually works. But this is difficult, because the language syntax is optimized for English-likeness, rather than being optimized for making it clear just what the f**k is actually going on.

This is why Python and JavaScript, two other scripting language of roughly the same vintage as AppleScript, are not only better languages than AppleScript, but are easier than AppleScript, even though neither is very English-like at all. Python and JavaScript's syntaxes are much more abstract than AppleScript's, but they are also more obvious. (Python, in particular, celebrates obviousness.)

AppleScript's natural language metaphor turns out to be more of a curse than a blessing.

Some languages are arguably more readable than others, of course, but keeping the goal of clarity front and center is far more important than bickering about relatively meaningless language choices. You can write FORTRAN in any language, so choose whatever language you're most comfortable with and optimize for making it clear what the f**k is going on.

(I thought about letting the f-bomb drop in this post for emphasis, but my fireball isn't quite as daring as John Gruber's.)

Game Player, Game Programmer

Greg Costikyan's essay Welcome Comrade! is a call to arms for hobbyist game programmers:

Back in the day, it took a couple of man days to create a Doom level. Creating a Doom III level took multiple man-weeks. Thus budgets spiral every upward; as late as 1992, a typical computer game had a budget of $200,000. Today, 10 million dollars is your bare buy-in for a next generation title.

As budgets soar, publishers are increasingly conservative about what they will fund, because nobody wants to lose 10 million dollars. So they look for ways to reduce their risk. Today, they have become so risk-averse that anything other than a franchise title, a game based on a movie license, or a game that slots easily into a category they know how to sell is unthinkable.

Today, Myst, Civilization, or Sim City would never get funded.

We're condemned to more of the same-old same-old from now for all eternity--unless we figure out a way to break this iron grip--what Raph Koster calls "Moore's Wall."

We think it's possible-- by building for the game industry what the independent film and independent music movements do for their own industry. Creating a viable "independent games" movement, where people can experiment, at lower budgets and with less risk, on quirky, offbeat, innovative games-- and find an audience that prizes gameplay over glitz, innovation over graphical trickery, playfulness over polygons.

Greg's Manifesto Games website aims to make this a reality, by creating an audience and supporting hobbyist developers.

James Hague's Rise and Fall of the Hobbyist Game Programmer documents just how profoundly the world has changed for would-be game programmers in the last 30 years:

For a small percentage of enthusiasts, there's always been the calling to jump from just playing games to creating them. It's crazy, of course, because the rush of playing a great game doesn't carry over to spending twenty straight hours in the basement trying to figure out why a level initialization routine fails ten percent of the time. But those that persisted, they drove the industry in its early days.

I remember reading about Mark Turmell-- and others whose names I've forgotten-- who were somehow inspired to design their own games, and then sit down and figure out exactly how to turn them into something their friends could actually come over and play. Those were fantastic feats that started the chatter about computer games becoming a new art form. One person, one vision, and six months later a finished product that was snapped up by a publisher--pure creation. A new alternative for would-be novelists.

The dream is still alive in these days of 32-bit processors and 3D accelerators, but over the years the reality behind it has quietly slipped away and few have stopped to notice.

In 1981, personal computers were in the thick of their 8-bit heyday. Not only are we talking about an 8-bit 6502--a processor with one primary register and no multiply instruction--running at less than 2 megahertz, but it was still acceptable, though just barely, to write games in BASIC. Now don't get me wrong, BASIC was the downtrodden interpreted language that it still is, but it shipped with every Apple II and Atari 800, and was the obvious choice for budding programmers.

Perhaps this is another reason why the Visual Studio Express IDE should ship with Vista. Or maybe doing it as-is with the .NET 2.0 command-line compiler and Notepad is more authentic. For more perspective on how the game programming world has changed since those early days, I can highly recommend James Hague's essential 1997 e-book Halcyon Days: Interviews with Classic Computer and Video Game Programmers.

Perhaps it's a little easier to imagine transitioning from gamer to programmer in the world of mobile devices. Lightworks games is doing just that-- two guys pursuing their dream by building a game company from the ground up on the PocketPC. They started with Cavemen, a charming little Lemmings clone.

There's also Microsoft's intriguing XNA Game Studio, which is now available in beta. It's a way for hobbyist developers to write non-commercial games that run on the Xbox 360. There have been rumblings about the best of these non-commercial games eventually making their way to the Xbox Live marketplace-- which could potentially convert those hobbyist game programmers into small business owners. It's an exciting prospect, given the huge installed base of most consoles, and the ease of getting everything running on a standard console platform.

Is the dream of jumping from game player to game programmer still alive? It's certainly how I got my start in programming.

Thread Priorities are Evil

Programmers* love to futz around with thread priorities. As if programming with threads wasn't already dangerous enough, we've got to get in there and tweak thread priorities to make things run.. er.. "better".

Let's fire up Task Manager and take a quick survey of process priorities. Out of 38 processes running on my computer right now, I have 0 at low priority, 36 at normal priority, and 2 essential system processes (csrss and winlogon) running at high priority.

I bet almost every process on your machine is running at a base priority of "Normal", too. And there's a very good reason for this.

Witness K. Scott Allen's strange threading experiment:

This program behaves badly on a single processor machine, and pegs the CPU at 100% for over two minutes. On a multi processor machine, the program finishes all the threading work in the blink of an eye - only a brief CPU spike.

Strangely, if I remove a single line of code:

t.Priority = ThreadPriority.BelowNormal;

… then the program performs just as well on a single processor machine (only a brief spike - comparable to the multi processor scenario).

This little threading demo highlights one of the reasons a dual-core computer is so desirable -- it protects you from poorly written programs. If a program goes haywire and consumes 100% of CPU time, you still have a "spare" CPU waiting to pick up the slack. Whereas a single processor machine becomes totally unresponsive. That's why Task Manager itself runs at High priority-- so you can pre-empt these kind of runaway apps.**

Hardware fixes to software problems are never pretty. What's really going on here? Joe Duffy is something of an expert on the topic of threading and concurrency-- he works for Microsoft on CPU-based parallelism in the .NET Common Language Runtime-- and he has this to say:

Messing with [thread] priorities is actually a very dangerous practice, and this is only one illustration of what can go wrong. (Other illustrations are topics for another day.) In summary, plenty of people do it and so reusable libraries need to be somewhat resilient to it; otherwise, we get bugs from customers who have some valid scenario for swapping around priorities, and then we as library developers end up fixing them in service packs. It's less costly to write the right code in the first place.

Here's the problem. If somebody begins the work that will make 'cond' true on a lower priority thread (the producer), and then the timing of the program is such that the higher priority thread that issues this spinning (the consumer) gets scheduled, the consumer will starve the producer completely. This is a classic race. And even though there's an explicit Sleep in there, issuing it doesn't allow the producer to be scheduled because it's at a lower priority. The consumer will just spin forever and unless a free CPU opens up, the producer will never produce. Oops!

The moral of the story? [Thread] priorities are evil, don't mess with them.

Although there are some edge conditions where micromanaging thread priorities can make sense, it's generally a bad idea. Set up your threads at normal priority and let the operating system deal with scheduling them. No matter how brilliant a programmer you may be, I can practically guarantee you won't be able to outsmart the programmers who wrote the scheduler in your operating system.

* and users who think they're programmers
** assuming the runaway app itself isn't running at High priority, in which case you're in a world of hurt.

The Sporkfe

Why does the sporkfe fascinate me so?

It's a spoon. It's a fork. It's a knife. Some call it a splade-- sold commercially in Australia for the last 50 years under the Splayds brand name-- but I prefer sporkfe. Really, when was the last time you ate your food with a blade?

I have no idea why I bought these. But at least I saved myself from the indignity of owning the Mother of All Swiss Army Knives.

How to Write Technical Documentation

I was browsing around the CouchDb wiki yesterday when I saw Damien Katz' hilarious description of how technical documentation really gets written. You know, in the real world:

Welcome to the world of technical documentation!

The situation you are in is no different from any other tech writer. The technical writing process:

1. Ask engineer how the damn thing works.
2. Deafing silence.
3. Crickets.
4. Tumbleweed.
5. Just start writing something. Anything.
6. Give this something to the engineer.
7. Watch engineer become quite upset at how badly you've missed the point of everything.
8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
9. Collect these nuggets, as they are the only reliable technical information you will receive.
10. Try like hell to weave together this information into something enlightening and technically accurate.
11. Go to step 6.

Ok, you're not the doc writing type. That's okay, neither am I. However, people are already working to make this better, and I will continue to do so.

I think I've been on both ends of this exchange at some point in my career. It's funny because it's true. I'm sure I've read descriptions exactly like this on Mike Pope's blog.

The Programmer's Bill of Rights

It's unbelievable to me that a company would pay a developer $60-$100k in salary, yet cripple him or her with terrible working conditions and crusty hand-me-down hardware. This makes no business sense whatsoever. And yet I see it all the time. It's shocking how many companies still don't provide software developers with the essential things they need to succeed.

I propose we adopt a Programmer's Bill of Rights, protecting the rights of programmers by preventing companies from denying them the fundamentals they need to be successful.

1. Every programmer shall have two monitors

   With the crashing prices of LCDs and the ubiquity of dual-output video cards, you'd be crazy to limit your developers to a single screen. The productivity benefits of doubling your desktop are well documented by now. If you want to maximize developer productivity, make sure each developer has two monitors.

2. Every programmer shall have a fast PC

   Developers are required to run a lot of software to get their jobs done: development environments, database engines, web servers, virtual machines, and so forth. Running all this software requires a fast PC with lots of memory. The faster a developer's PC is, the faster they can cycle through debug and compile cycles. You'd be foolish to pay the extortionist prices for the extreme top of the current performance heap-- but always make sure you're buying near the top end. Outfit your developers with fast PCs that have lots of memory. Time spent staring at a progress bar is wasted time.

3. Every programmer shall have their choice of mouse and keyboard

   In college, I ran a painting business. Every painter I hired had to buy their own brushes. This was one of the first things I learned. Throwing a standard brush at new painters didn't work. The "company" brushes were quickly neglected and degenerated into a state of disrepair. But painters who bought their own brushes took care of them. Painters who bought their own brushes learned to appreciate the difference between the professional $20 brush they owned and cheap disposable dollar store brushes. Having their own brush engendered a sense of enduring responsibility and craftsmanship. Programmers should have the same relationship with their mouse and keyboard-- they are the essential, workaday tools we use to practice our craft and should be treated as such.

4. Every programmer shall have a comfortable chair

   Let's face it. We make our livings largely by sitting on our butts for 8 hours a day. Why not spend that 8 hours in a comfortable, well-designed chair? Give developers chairs that make sitting for 8 hours not just tolerable, but enjoyable. Sure, you hire developers primarily for their giant brains, but don't forget your developers' other assets.

5. Every programmer shall have a fast internet connection

   Good programmers never write what they can steal. And the internet is the best conduit for stolen material ever invented. I'm all for books, but it's hard to imagine getting any work done without fast, responsive internet searches at my fingertips.

6. Every programmer shall have quiet working conditions

   Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers' flow state, otherwise they'll waste most of their time bouncing back and forth between distractions.

The few basic rights we're asking for are easy. They aren't extravagant demands. They're fundamental to the quality of work life for a software developer. If the company you work for isn't getting it right, making it right is neither expensive nor difficult. Demand your rights as a programmer! And remember: you can either change your company, or you can change your company.

Coding Horror Sightings

The free stickers were all mailed Monday. Here's a quick statistical breakdown, courtesy of my wife:

38 of the 50 states were represented. The states with zero sticker requests were: HI, KS, LA, MS, MT, ND, NM, RI, SD, VT, WV and WY. Here are the top 10 states:

And here's a similar breakdown for Canadian provinces:

Contrary to popular belief, I am fully aware that the United States isn't the only country in the world. Here's a breakdown of the international orders to date:

Although the free sticker offer is over, you can still buy a set of 4 stickers for $3. They're usually mailed the same day.

Will Sullivan's is appropriately positioned next to a real coding horror.	Bryan Likes created the infinite cat project recursive version.
Here's one from my fellow developers at Vertigo. If you work with me, I'll give you a sticker. But only grudgingly.	Sam Livingston-Gray put his to good use covering up that hideous Apple logo. Bonus points for real-life simulation!
Matt Blodgett evidently doesn't own a digital camera. But he does have mad MS Paint skills.	My old friend Geoff Dalgas created this animated version of the sticker.
Brian Stephens works on Titan Quest, which doesn't play like a Coding Horror.	Bryan Kramer sighted his at a Jacksonville, Florida Code Camp during a marathon not-for-profit coding session.
David Howell gave his sticker a place of honor in his cube.	Nathan Birkes used his sticker to pimp out his Grand Prix. Stylin'!
Steve Makofsky works at Microsoft. Guess what part of Vista he worked on?	Martin Marconcini is going for sticker symmetry on his Ford Focus.

If you have any Coding Horror sticker or T-shirt "action shots", email them to me, and I'll post them here.

Building a Quiet PC

When the first version of Windows Media Center was released in summer 2003, I decided it was time to build my first home theater PC. After I placed it in the living room, I realized I had made a terrible mistake: I had to turn the volume up to 11 just to drown out the noise of the HTPC! I couldn't believe how loud it was! For the next few months, I immersed myself in the world of silent PC enthusiasts. I must have reconfigured that system a dozen times to reduce the noise.

Now every PC I build is optimized for performance and low noise from the very beginning.

Anyone can build a high-powered rig that sounds like a jet taking off. Building a high-powered rig that's so quiet your wife can't tell when it's turned on or off-- now that's an accomplishment! It's a bona-fide engineering challenge.

In the process, I've learned quite a few things about building quiet PCs. I'd like to share them with you, so you can avoid making the mistakes I did.

1. The easiest way to build a quiet PC is to start with components that run cool. It's as fundamental as the first law of thermodynamics: heat has to be exhausted from the system; more heat equals more noise. If you truly want a quiet system, start with cool running components. The three components that generate the most heat in your system are..
   1. CPU
   2. video card
   3. power supply

   .. in that order. Select these items very carefully, because they will account for 90 percent of the heat and noise generated inside your computer. Research how many watts of power each will draw when idle; when normally loaded; and when fully loaded.

   And don't underestimate the importance of the power supply; it's the heart of your system, and it can be the source of serious stability, noise, and heat woes if you pick a clunker. The very best power supplies are only about 85% efficient, which means they're still dumping 15% of the total power draw back into your case as waste heat.

2. Minimize the number of fans in your system. Every fan is a source of noise. Remove fans unless they're absolutely necessary. If a fan is necessary, use the largest possible model. All other things being equal, large fans are quieter than small fans. That's why 120mm fans are now commonplace in PC cases.

   One of the most useful noise diagnostics is to stop every fan in the system, one by one, using your Mark I finger. Repeat this a few times, listening closely to hear the difference with each fan stopped. Then try to eliminate or slow down the noisiest fan. Don't forget to test your video cards and motherboard fans while you're at it; these tend to be particularly noisy due to their small size. And remember, kids, always stop fans by touching them in the center, not in those whirling blades!

3. Control the speed of your fans. Fans running at full speed are almost never quiet. Some modern motherboards allow you to control the speed of the fans connected via the 3-pin motherboard headers, either in the BIOS or in software. Set an absolute speed, or even better, use dynamic fan speeds based on a temperature sensor; spin faster when it gets hot, and slow down when things cool off. There are also devices like the Zalman Fanmate that allow you to retrofit a fan speed control on any 3-pin fan.

   

   The Zalman 56 Ohm resistor is a less expensive option if you don't need precise speed control.

4. Consider aftermarket cooling solutions. Aftermarket coolers for CPUs and video cards are typically far more efficient than the stock models manufacturers include. You might be able to get away with inefficient stock coolers for basic systems, but if you want high-end performance, a super-efficient cooler can literally be the difference between a quiet system and a loud system.
   • The current top dogs for CPU cooling efficiency are tall heatpipe stack designs such as the Thermalright Ultra-120 and the Scythe Ninja.
   • The current top dogs for VGA cooling efficiency are copper heatpipe designs, such as the Arctic Cooling Accelero X1 and the Zalman VF900-CU.
   • Consider replacing any small fan and heatsink combinations -- such as the ones commonly found on motherboards -- with larger, passive coolers. Two great options are the Zalman NB47J and the newer, flower style Zalman NBF47.

      

   Note that aftermarket coolers tend to be quite a bit larger than stock coolers; measure to make sure they'll fit in your system before buying.

5. Dampen your hard drive. Hard drive manufacturers have made huge strides in noise reduction in the last few years. You still need to be a bit careful in selecting a drive, but most new hard drives are relatively quiet. That's the good news. The bad news is that hard drives are still giant hunks of metal spinning at 7,200 or 10,000 RPM.

   As such, the first order of business here is to dampen the drives -- make absolutely sure there is a soft material of some kind between the hard drive and your PC's case. Some people improvise bungee suspension slings, some people use foam or sorbothane, some people put them in dampening enclosures. Whatever you do, always avoid metal-to-metal contact between a hard drive and the case.

   

   The truly hardcore use 2.5" laptop hard drives, which are even quieter, but they also have significant performance and price penalties over standard 3.5" desktop drives.

6. Use noise-reduction materials. If you've ever worked in a recording studio where the walls are covered with noise-reduction materials, you've probably heard first-hand how effective they can be. However, noise reduction materials are strictly a second line of defense. They treat the symptom and not the source; ideally you want to quiet the thing that is making noise-- not hide it behind a layer of dampening material.

   That said, noise reduction materials can help take the edge off the last remaining bit of noise in a system. For PC builds, I like pax.mate and generic eggcrate foam. You can see pictures of both materials in action in this SilentPCReview thread documenting a LAN party system I built in summer 2004. But they should always be a final, finishing step.

   

   I'm ashamed to admit that I have something of an eggcrate foam fetish. In addition to wedging it inside my systems wherever it'll fit, I regularly put cardboard-mounted panels of the eggcrate foam behind my PCs to reduce the reflected noise from the rear exhaust fans. If your PC is under a desk, fitting eggcrate foam along the undersides of the desk can be surprisingly effective, too.

7. Passive cooling isn't worth it. If you really get bitten by the silence bug, you'll invariably be drawn to that holy grail of silent computing: completely passive cooling. Passive cooling is totally silent by definition, but also it's the equivalent of scaling the Himalayas-- not something you undertake lightly and certainly not without a few years of experience under your belt.

   Although there are exotic pre-built passive solutions like Zalman's TNN-500A and TNN-300 cases, they're solidly in the "if you have to ask how much it costs, you can't afford it" category.

   

   Passive cooling setups are an order of magnitude more difficult to cool: they require a tricky balance of careful construction, natural convective airflow, and setup tweaking. You can achieve 90 percent of the results you'd get with completely passive cooling using a few nearly-silent, slow-moving fans-- at a fraction of the effort and risk!

I can't emphasize enough that the best way to quiet your PC is to begin with the right parts. If you're really serious about silence, ensure that you have..

• CPUs and video cards that run cool
• a quiet, efficient power supply
• hard drives that run relatively quiet as shipped

Always try to deal with the source of the noise first. Beyond that, following the few tips I outlined above will eventually get you to near-complete silence-- or at least to below-ambient noise level, which is pretty much the same thing.

Total Users Does Not Equal Total Usage

As of August 9th, 2006, MySpace has 100 million members. For reference, the population of California is approximately 36 million, and the population of the United States is approximately 300 million.

I have a hard time believing that 1 in 3 Americans could conceivably be MySpace users.

I'm not the only person to be skeptical of these inflated "member" numbers. Robert Scoble recently took issue with the claim that Windows Live Spaces is the largest blogging service on the planet. He did a little ad-hoc investigation of Windows Live Spaces. Most of the member pages he visited were virtual ghost towns.

Dare Obasanjo addresses this criticism head-on:

The number of spaces on Windows Live Spaces isn't a particularly interesting metric to me nor is it to anyone I know who works on the product. We are more interested in the number of people who actually use our service and get value added to their lives by being able to share, discuss and communicate with their friends, families and total strangers.

Kudos to Dare for cutting to the heart of this debate. Who cares how many users signed up for your free service? How many users actually use it?

To illustrate the absurdity of user counts as a metric, Dare cited the LiveJournal stats page. According to that page, LiveJournal has approximately 11 million accounts. However:

• 1 in 3 accounts are never used.
• 1 in 5 accounts are "active in some way".
• 1 in 10 accounts updated in the last 30 days.

If the LiveJournal statistics are representative of other social networking websites, then we should immediately divide the total number of "users", "spaces", or "accounts", by five. Maybe even by ten! That's a realistic estimate of how many people are actually using the service.

Total number of LiveJournal accounts:

11 million

Total number of active LiveJournal accounts:

1.5 million

And that's still an optimistic estimate, because it doesn't factor in multiple accounts established by the same person.

Now if only MySpace and Windows Live Spaces would be as forthcoming about the actual usage of their service, instead of bandying around meaningless user counts.

DirectX Version Number Abuse

Has anyone noticed that Microsoft defines "version" a little loosely when it comes to DirectX 9.0c? Here's a screenshot of the DirectX 9.0c download page on FileHippo:

DirectX 9.0c was originally released in August 2004, according to the DirectX Wikipedia entry. But Microsoft has surreptitiously been updating DirectX 9.0c since August 2005 without incrementing the version number.

It is not known why Microsoft has not used new version numbers for the updates to DX9.0c -- including the December 2005 update versioning could now be at DX9.0j, although this is nowhere reflected in the internal code.

So do you want version 9.0c, 9.0c, 9.0c, or perhaps.. 9.0c?

The versions are all fully backwards compatible, of course, but why is Microsoft abusing version numbers this way?

It's impossible to tell what version of DirectX 9.0 you're actually running. I've installed several games over the past year which inexplicably demanded to re-install DirectX 9.0c; now I know why.

At least Vista stops the madness by finally changing the version number to DirectX 9.0L.