NSLog();

Joel Spolsky has posted another "Microsoft is Stupid" missive at joelonsoftware.com. Many of his points are valid, and his main point is rather lucid, but one paragraph stood out for me as a Mac user and developer.

The toss-aside paragraph comes in a section in which Joel talks about Microsoft's engineering efforts in getting old applications working on new OSes. Joel tells the story of SimCity, which relied on a hack to quickly do some things, and which broke on a newer version of Windows. Microsoft added code to Windows that preserved the old "broken" way of doing things when SimCity was active. Joel holds this up as "A Good Thing™" before launching into this:

A lot of developers and engineers don't agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It's why so few applications from the early days of the Macintosh still work.

Funny, but I remember seeing screenshots of MacPaint, MacWrite, etc. running in Classic mode when Mac OS X (Public Beta or 10.0) was released. Here's a screenshot of SuperPaint from 1993 running on Mac OS X 10.2.8. Classic mode was hailed as a pretty great way to bring even the oldest of applications along (thanks Will Scherrer).

If code is written poorly, I believe it should break. Hopefully it breaks immediately, during development, but better late than never. It's a developer's responsibility to write decent, proper code, not to cheat the system and use undocumented APIs. Apple has not been accused of using hidden APIs nearly as frequently as Microsoft has, so perhaps it's easier for Apple to remove from, add to, or otherwise modify hidden or unsupported APIs because so few of their own end-user software relies on them.

A private API is a private API. A developer takes a known risk when they implement something that's not publicly documented or supported. This risk is then passed on to an unknowing consumer. Blaming Apple (or any OS maker) for changing how unsupported, hidden, or "hacky" things work is ridiculous. The blame belongs with the developer who took a known risk in using the API to begin with.

Joel relies on one of the worst tactics for supporting a point: not supporting his point. "It's why so few applications from the early days of the Macintosh still work" is such a silly claim as to seriously damage his credibility as an observer of computing history and a purveyor of solid opinion.

For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple's official Bible of Macintosh programming, there was a tech note saying "you can't do this," they did it, and it worked, and their programs ran faster… until the next version of the OS came out and they didn't run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby.

This portion disgusts me. "Most" of these companies went out of business because Apple disallowed something it had never explicitly allowed to begin with? Please. Perhaps Joel is not saying this - he's "correct" in his vagueness by saying that the companies only went out of business, not how - but the inference is there. Furthermore, he fails to provide any sort of proof. Granted, this is not the purpose of his article - but why include "factual" information devoid of facts?

The developers chose to use an unsupported method to gain some speed. That's not "tough luck," that's a decision. I don't chalk up things I have control over to luck, and neither should Joel: it shifts blame from those who are responsible (the developers) to those who are not (the OS vendor).

Joel makes solid points in this article, but my opinion of him continues to erode with each time he takes pot shots for no real reason. Unsupported, flamebait comments such as these serve no purpose in what I hope is an otherwise upstanding editorial.

Comments RSS