Solipsism Gradient

Ted Landau of MacFixit fame interviewed me last Wednesday and the interview is up now on the Mac Observer. Many thanks to Ted for this opportunity to get word out about the upcoming Quay plug-in SDK.

A few small corrections:

…I also had a job working with the Macs installed at a medical equipment company…

what I said was that, at that company, I designed medical equipment based on a Mac-like architecture (68K processor and all) and used a Mac as a development workstation.

…The staff here at the WWDC have always been helpful, although probably a bit more so back in the 1990′s than now…

I actually was referring to the people at developer relations, not at WWDC, and the situation is reversed; they’re a bit more helpful now, since in the 1990′s they hadn’t quite gotten their international act together, and I depended more on personal acquaintance with some of the Apple folks.

The conference will be over tomorrow and I’m quite satisfied with the outcome. Now for some comments about the announcements and (NDA permitting) about what I learned.

I had some vague idea of going to some iPhone sessions and letting presenters (or friends developing for the iPhone) convince me that I should start developing for it. No such thing happened; session overlap was so severe, and there were so many labs to go to, and people to talk to, that I skipped any non-Mac session or discussion. What little I heard in the corridors confirmed my notion that the current state of iPhone development and the AppStore deviates too far from my preferred position as a utility developer – a niche Apple still keeps closed on the iPhone. Maybe when the tablet comes out…

Speaking of tablets, while everybody agrees that one is in the works, it seems to be a year or so away from announcement. (Ditto for the new CPUs I hinted at, in my last post.)

Snow Leopard is the small new thing. Small for the user in a sense; it’s just refinements and greater speed. For developers, though, it’s the BIG new thing. And, as variously described as early as a year ago (can’t find URLs right now), much of the new stuff is driven behind the scenes by open-source projects Apple is driving: the Clang compiler, the LLVM back end, and the technologies made possible by Grand Central Dispatch, blocks and OpenCL. So, most of the sessions either expanded on this directly or offhandedly mentioned “there’s an API for that now – and it’s fully XYZ-enabled” (insert one of the technologies above).

These things have become possible because CPU chips had run into a clock frequency “sound barrier”; 3GHz is about the maximum current silicon can do without extensive and expensive cooling or exotic technology. So multicore has become the solution du jour: all Apple computers now have at least 2 core, and the top machine has 8 (16 virtual). Expect that number to double every 2 years, at least.

But for years multi-processor machines were hard to program. About 14 years ago, at another WWDC I bought a Genesis MP 528: this Mac clone had 4 PowerPC 604 processors running at a blistering 132MHz. It didn’t have much caching on those chips, and only Photoshop and a few other specialized apps could see more than one CPU, and that only for image filters. In two years the first PowerPC G3 CPU card, with a single processor but caching, running at 300MHz, had about the same Photoshop performance – and that performance was then available to all apps. So why didn’t more apps take advantage of the 4 CPUs? The classic Mac System 7 (to 9) had no easy way to allow for this; there was a very primitive multiprocessing API but the system was pretty much locked out of it.

As said in the keynote, Snow Leopard will support only Intel Macs; PowerPC Macs are, therefore, stuck in the Leopard era, and only some few bug fixes will appear on 10.5, then it’s over. I couldn’t find hard figures comparing the installed base; I’ve seen percentages quoted of between 10 and 35% of Macs Macs still in use being PowerPCs. I personally didn’t think this would dip below 25% before 2011; then again, as a stockholder, I’m glad Apple sold so many new Macs recently…

Some people question why PowerPC users will be left out of the Snow Leopard advantages, and I think I know why. While the top 4-CPU PowerPC machines still can hold their own with more modern machines under certain circumstances, the vast majority of PowerPC Macs have only 1 CPU; only a few big desktops have 2, and even fewer have 4. Most advantages of Snow Leopard come into play when you have at least 2 CPU cores, and there’s serious testing and bug fixing to be done for supporting an entire architecture. Apple probably just weighed those factors (with better numbers than I have available) and decided it wouldn’t work out.

Positives of the new Clang/LLVM combo: better compiler speed, better code optimization – both still starting out but they’ve more power in reserve, while the current gcc compiler and backends are pretty much maxed out; way better error messages, the Clang static analyzer is just awesome (a word I usually hesitate to use, but this really is!); lots of goodies to come from tighter integration with Xcode. Negatives: may still generate wrong/inefficient code in some circumstances; no C++ support yet (I don’t care myself about this one).

A sleeper advantage is, also, that the intermediate (LLVM) bytecode generated by Clang could possibly be stored as such inside executables, and be just-in-time compiled for execution on any target CPU. In other words, the same executable could run on a new machine Apple puts out, even if it has a new CPU chip/architecture, as long as the JIT compiler is in place for that; application developers wouldn’t have know (or care).

Regarding blocks (or “closures”, as they’re known in other places), they’re a syntactic convenience for programmers to pass executable code as data. As such, they make programs more readable. What makes them inordinately powerful in Snow Leopard is that they’re also the basic executable units for all of the cool new multiprocessing stuff in Grand Central Dispatch. Therefore, with a little discipline, it becomes easy for developers to chop up tasks into little slices than can be executed in parallel by however many CPU cores (or, with OpenCL, GPU units) are available to do them; and for the first time anywhere I know of, this facility is available throughout the system, even at a quite low level.

So, am I running off to convert all of my code to the new technologies? Well, yes and no. Many things still have to be done in a serial manner, and the system will do others in parallel behind my back. Also, it seems that writing a generic application that runs on both 10.5 and 10.6 (using the new stuff) is tricky; I’m still investigating how to best do it. Stay tuned for developments…

Well, the nice folks at MacMagazine (thanks Rafael!) have republished a slightly updated version of an interview I gave a few years ago. It’s mostly about the 1985 Unitron Mac512, the very first Mac clone.

It’s in Portuguese, so here’s a translated-by-Google sort-of-English version. Rafael has hunted down some good pictures of an early prototype; I regret not having taken any myself.

While most of yesterday’s Macworld keynote was uninteresting to me personally – I rarely use any of the updated software, and don’t have iTunes store access – the new 17″ MacBook Pro was mostly as I expected: the additional space was used for a larger battery, and more USB ports.

It was gratifying to see Apple’s battery page practically repeat my reasoning about the infrastructure (and wasted space) needed to accommodate removable batteries. (See also Chuq Von Rospach‘s discussion of the issue.) Not that the 15″ model’s infrastructure is quite as large as they show in the video, of course… but it makes the point well.

Judging from the pictures, the hard drive is inside a space that’s almost exactly square. In theory, they could have rotated the drive 90 degrees and made the battery 30mm wider, for maybe 10% more capacity. So why didn’t they do that? It would have meant extra weight, a beefed-up charging circuit, more heat dissipation, and either a larger power supply (which already is at 85W) or a longer charging time.

I don’t doubt that we’ll see incremental upgrades for iMacs and Mac minis rolled out without much fanfare over the next two months. My tip for the iMacs is that they’ll use the exact same front and back bezels as the corresponding-sized displays, with only a 10mm shim module inserted to accommodate the CPU and drives. The advantage, of course, would be that you could add a second display to your iMac with the exact same styling, screen parameters, and height; a good selling point. It would be a no-brainer for the 24″ model. I’m not sure that a 20″ display from Apple would sell well by itself, but if it used bezels and nearly all components from the 20″ iMac, it might be price competitive, and the styling advantage would be worth paying a few bucks extra. A 28″ iMac has been rumored; would that, then, mean that the current high-end 30″ display would be shrunk to 28″ too? I hope we’ll have the answer soon.

It’s been a couple of weeks since my last post, but I haven’t been idle. Well, a few of the holidays excepted, of course. Here’s what’s on my radar for the new year, or at least for the first months.

I’ve finally had time to look at the SnowLeopard (Mac OS X 10.6) beta. Can’t say much about it, except that there are interesting and significant changes in the infrastructure – important for programmers. I really hope that, once out, a majority of users will adopt it.

A consequence of seeing the 10.6 APIs is that I decided to do a serious rework of Klicko and Quay, so they’ll be ultimately easier to migrate to 10.6 and a 64-bit environment. Klicko inherited a lot of code, and I’m really glad that I decided to do it as a training exercise, since I’ll very soon back-port much of that back to Quay, after enhancing and optimizing.

If all goes well, Klicko 1.1 will be out soon. I’ve got all but installation and updating procedures done. Most notably, it’s now a System Preferences panel that installs a background process. While this is a departure from the easy-to-run, simple-Cocoa-app mantra, splitting this type of application into a faceless background process and a foreground GUI will soon be mandatory for all practical purposes, and there are advantages; for the user, once properly installed and configured, Klicko will “just work” automatically and in the background, and use very few resources.

One new Klicko feature was requested by several users (and others who have emailed me in the past). There will be a (configurable) preference to have the window’s “zoom” button do a true maximize – or at least attempt to, not all applications will support it properly. While I find the importance that Windows users attach to maximizing everything all the time a little puzzling, trying it out convinced me that it’s useful now and then. I always maximize NetNewsWire, Xcode, and a few other application windows, for instance. I also decided that it may be useful in pointing users that are new to the Mac to shareware software in general and to my own applications.

Once that is done – hopefully with very few build updates – it’s back to reimplementing everything I learned into Quay (probably 1.2). I’m not decided whether that will become a preferences panel too, but it may be possible. More importantly, I’m now pretty fluent with the event tap and accessibility APIs that both Quay and Klicko use.

The major new feature of Quay will be that Quay menus will also pop up for Finder icons. Ultimately, I’d like to make this work in any and all Finder window modes – icon, list and column – and in all circumstances where the Finder’s own contextual menus pop up. I’ve done some preliminary testing and it looks like it might be possible. There are a few edge cases where I’m not sure that I’ll be able to compute the correct path for the icon.

Anyway, if all works as planned, I’ll be able to introduce more flexibility through plug-ins. A plug-in would get a file or folder handed to it and would produce either a popup menu, or an information window. This would allow me to finally declare XRay entirely defunct (it already runs very poorly on Leopard), and replace it with many small, specialized plug-ins. My older contextual menu plug-ins, like Zingg! and Nudge would also be trivial to rewrite as Quay plug-ins.

A similar, much more ambitious plug-in scheme, was planned for XRay II, and I can reuse some of that code… there are still some complex issues to decide, however. Opening the plug-in interface to other developers is of course what I’d like to do, but licensing, updating, keeping plug-ins from interfering with each other will be very tricky.

All in all there’s lots of ideas to implement and this should keep me busy for most of the year. I’m not considering going into iPhone/iPod development for now; there’s a glut of $0.99 applications and the way the App Store is working seems overly opaque to me.

More soon! Stay tuned.

Klicko 1.0b4 is just out. It’s a little smaller and, despite that, is localized into Portuguese.

I switched some stuff around so that any new localizations will add only two small text files to the app. Localizers, please tell me if you’re interested.