Are standards really that difficult? Webkit hits Acid3 in their nightly builds.

I like Joel Spolesky. He’s a great writer, and he’s got a good head for managing software. But he is blind to Microsoft’s insanity, taking the agnostic-zealot position. I can forgive him, though, as he writes passionately and is willing to question the other zealots.

What Joel and the other flamers have missed is that standards conformance is easy, if you can pull your head out of your ass long enough to realize that it’s already solved. If Microsoft could place nicely, they would be able to cooperate and join the Webkit fray. The world would be a better place.

Apple, Nintendo, and others have figured it out. Why build your own browser? Why not just pitch in to an existing effort, or license something? Standards are easier if you don’t insist on building it yourself.

Standards are easy. It’s NIH that is difficult.

I’ve heard a few complaints about the new iPhone SDK, but I just realized (re-watching the demos) that Apple chose OpenGL and OpenAL. That’s big. They’ve picked a beautiful pair of APIs and put them in the hands of thousands of excited developers.¹ They’ve also picked other great tools like SQLite, Bonjour, and gcc … things that are vital for the health of the software industry. Yay standards!

1. Compare to Microsoft’s seemingly-insane approach of NIH ↩

Dean Edwards has released a new version of his magic make-IE-suck-less script, which brings IE within reach of standards.

I’m tired of wrapper libraries. They’re a cognitive consumerism gone awry, wrappers for wrappers wrapping wrappers. Every development team I’ve known has their own¹, each somehow better than the others, most ignoring the long history of thinking gone into libraries written throughout computing history.

What’s wrong with using the basic standard libraries, ported where they don’t exist? I mean, really, why do we need another date class, or another wrapper on file paths?² Are you or your development team so challenged that you can’t reliably use fopen or fprintf? Is your own brew of file.Open() more reliable than, say, C#’s, Java’s, Perl’s, the STL’s (or whatever toolchain you’re immersed in)?

I’ve heard the excuse that standard libraries fall short in some way: maybe they’re not available for a required platform, or maybe they’re missing a key set of functions. Then port the libraries (there are enough free implementations out there), or add a companion library, class, or unit. It’s really not that difficult. Re-wrapping the entire damned universe should be left to the crazies with their tin-foil hats and couches covered in plastic. And the standard libraries aren’t so bad that you need to be protected from them. In fact, they’re pretty damned good, once you’re willing to get over your own ego.

I think that teams are looking at the problem of abstraction the wrong way. Wrapping concepts in your product’s domain is a good thing (as long as you don’t overdo it). But where’s the value in wrapping things that have thousands of existing implementations? Why repeat what’s been thought, built, and tested thousands of times over? Just learn the fucking standards, understand that they’re imperfect, and make peace with the fact that they don’t fit your personal mental model of things. Assume that where your mental model differs that it’s wrong or unimportant, because it probably is.

And if you’re not willing to use the standards, at least use the de facto libraries for the platform. If you’re targeting Windows prefer the Posix libraries³, then default Win32 libraries for your toolkit, and as a fallback, any absurdly popular library that has a vibrant community. The same goes for whatever platform you’re on. But if you’re tempted to write your own basic-concept-wrappers, in your own brand of library magic, then you’re full of shit. Get over it: you’re not that good. None of us are.

That’s why we share standards. That’s why out of thousands of class libraries, only a few bubble to the top. Only one or two of them are good enough to be worth using. Spend your time on problems related to your application, on the things that your users will actually care about.

1. And yes, I’ve fallen to this bug myself in decades past ↩
2. Companions to the standard libraries are good, as long as they don’t repeat what’s already available ↩
3. Because it’s the right thing to do ↩

Opera released a new version of their mini browser this week, and here’s how it fares on the ACID2 test.

Where developers can’t agree on code standards, separate them by interfaces. Sometimes the differences are good, indicative of other valid approaches (and backgrounds). Should we kill developer productivity by arguing K&R versus Microsoft standards? In the end it’s about solid code and productive people. The rest is bullshit.

A very reasonable code standard for Php, a worthy read for noobs.

A Google page rank guide.

Knowledge Software is providing a free pdf download of “The New C Standard: An Economic and Cultural Commentary”, which covers the C standard.