mikeash.com pyblog/friday-qa-2009-01-02.html comments

mikeash - 2009-01-06 03:28:04

Tue, 06 Jan 2009 03:28:04 GMT

Craig: Your point about public APIs breaking is a good one, and it's why I think that a policy of simply avoiding all private APIs forever doesn't make sense: it won't save you. As an example, I wouldn't hesitate to build an app around mach_msg() even though it's nominally private, but I'd give any significant app built with Objective-C garbage collection a 50% chance of breaking on Snow Leopard.

David: From my point of view Carbon was clearly a legacy technology and the smart move was to move away from it as much as possible. But perhaps from the other side this was much less clear. Apple's move to cancel Carbon 64-bit after promising to support it was undoubtedly very crappy and wrong. However when talking about how long stuff stays supported, I'll note that this cancellation didn't kill any shipping code. It made a whole lot of code bases much less valuable and destroyed a bunch of work, but it didn't cause any apps to suddenly break, so from the point of view of how long your shipping code will last, the continuing life of Carbon 32-bit is what counts. From the point of view of which technologies to rely on, obviously there's some kind of important lesson in the Carbon 64-bit cancellation.

David - 2009-01-06 00:00:33

Tue, 06 Jan 2009 00:00:33 GMT

I disagree with your statement about the equivalence between being shafted by Classic's cancellation and being shafted by Carbon-64's. 64-bit support for Carbon was a subject of discussion at the WWDC prior to the one at which it was cancelled. Classic wasn't even an API, it was a technology that allowed you to continue running Mac OS 9. Mac OS 9 was literally put in a casket on the stage at WWDC many years ago by Steve Jobs himself. And no updates to OS 9 had occurred for quite a while before that even. Carbon was still being advanced several versions in to Mac OS X, and large developers like Microsoft and Adobe depended on it for major applications. Even Apple still based Final Cut Pro, a perfect candidate for 64-bit support, on Carbon. So the writing on the wall for Carbon 64's cancellation was not anywhere near as clear as you make it out to be.

Craig Hunter - 2009-01-05 23:52:43

Mon, 05 Jan 2009 23:52:43 GMT

Good thoughts, but you are sort of positioning public APIs as a baseline "sanitary" reference for the discussion. We all know how many times those public APIs have gotten broken in OS updates. Or deprecated. Or, more commonly, public APIs get released with bugs that we all learn to work around, but later bug-fixes nuke the workarounds. There is some risk with using public APIs too. Their main benefit is that all this crap is documented in some form, but even that's not perfect. So I might be jaded, but private APIs are not as scary as they are cracked up to be.

mikeash - 2009-01-05 09:38:31

Mon, 05 Jan 2009 09:38:31 GMT

I think that we're more in agreement than disagreement. However I want to point out a few disagreements I have with what you've said.

First, while it's true that a lot of private API usage is fairly gratuitous, sometimes it's really essential. Not all private APIs can be easily replicated, and some can't be replicated at all. If your app depends on one which can't be replicated then you have little choice. The whole point of this analysis is to tell you which is which, and whether it's worthwhile.

Second, in my experience, there are extremely few users who won't give you a few days to fix your software but who instantly upgraed to any new version of Mac OS X that Apple releases. The vast majority of people are happy to keep up with updates. Of those who don't, the vast majority don't keep up with Apple's updates either.

Third, as I pointed out in my last message, avoiding private APIs won't always save you. There's always a chance that a major Mac OS X release will break your software even if you use 100% public APIs.

In any case I welcome disagreement and different opinions so please do continue!

Gazoobee - 2009-01-05 06:55:37

Mon, 05 Jan 2009 06:55:37 GMT

@ mikeash

Thanks for the thoughtful response and I agree (with what I infer is your standpoint), that perhaps I overstated my argument. Despite the undue vigour with which I argued it however, I think that it still stands.

From the point of view of the end consumer, using any API that is likely to change in any *reasonable* amount of time is (IMO) not good practice unless it's absolutely necessary to the design of the software. Of course, the developer is the one that has to make the determination as to what's a "reasonable" amount of time and what's necessary to the application, so in terms of practice, I'm probably not suggesting anything different from you.

As a technician but not a developer, (I haven't done any development work to speak of, but I do create and maintain huge complex databases so some of the same principles apply), I guess I'm not really in a position to argue anything definitively but I would still argue that *most* of the time, the use of private APIs is not always as necessary as it may seem at the time.

It's also true that by doing more work, one can avoid private API's altogether, so unless the amount of work involved is critical to the project, there is always the option of recreating the same effect "from scratch." A recent example is the creation of CoverFlow like interfaces from scratch on the iPhone instead of using the (private) API.

I think my main point was supposed to be more a critique of the concept of thinking you can "fix" things with a later release. In the real world, the customer might just as easily switch to your competitor's product than wait for you to fix a problem that shouldn't really be there in the first place. Anyway, I didn't mean to be hyper-critical anyway (if that's how I came across.)

mikeash - 2009-01-05 02:10:10

Mon, 05 Jan 2009 02:10:10 GMT

I certainly didn't leave out the customer's point of view. Go back and read the paragraph which starts with, "Remember that the cost is not just to you, but to your users." I may not have spent much time on it but I definitely didn't leave it out.

With the widespread use of built-in updaters, it's entirely reasonable to expect users to stay up to date. This is completely unrelated to "subscription software", which is software which requires periodic payments.

And don't think that avoiding private APIs is a surefire way to avoid breaking when a new version of Mac OS X comes out. Plenty of apps which use nothing but public APIs break. Often it's because they have relied on some behavior which is not guaranteed, typically completely inadvertently. Sometimes it's because Apple has decided that a particular API contract really needs to be broken. Sometimes it's because Apple accidentally broke that contract.

Anyone who has used computers for a while knows that installing a new OS release has a good chance of breaking at least some of their software. If you want to own software for life, then you need to be very conservative with OS updates or be willing to actually keep that software up to date. This is true whether that software uses private APIs or not.

Every developer engages in these trade-offs. If you avoid developers when you're aware that they're doing it, all you do is end up using products from developers who hide it better. Engineering is about tradeoffs, period. You think it's bad with software? Think about the tradeoffs that go into engineering every single car you ride in, bridge you drive or walk over, building you enter, and electronic product you use. Unlike software, those products have the potential to take human life. The engineers for those products are making a complex trade-off between cost, complexity, functionality, aesthetics, and risk to human life. And while they try to hold risk down as much as possible, you can be sure that the number they're assigning to risk is not zero.

Engineering is always about trade-offs. It holds true everywhere. Yes, as developers, we need to take our customers into account when making those trade-offs. But the answer is not to avoid making them, because that's simply impossible.

Gazoobee - 2009-01-05 01:09:06

Mon, 05 Jan 2009 01:09:06 GMT

You pretty much have it down from a developer's point of view (which was your intention I guess), but the one thing you are leaving out of your analysis here is the customer's point of view.

The whole concept of balancing possible code breakage with how hard/easy it would be to "fix it in the next release" leans rather heavily on the idea of subscription software or that the customers you sell to are going to be yours for life, deeply interested in always getting the latest version of your software, etc. etc.. None of this is actually true for the average software purchaser/consumer however.

The majority of people still buy software as a unitary "thing" as if it was a car or a toaster, and want it to work for a lot longer than the next point release. If as a customer, I was aware that the coder was engaging in these kinds of trade-offs I would purposely never buy from that source. Obviously most won't know, so you can continue with the methodologies that work for you as a developer, but this whole argument seems quite antithetical to the idea of making solid, "good" software that I as a consumer want to purchase.

This method will get you good software that any other developer would think was fantastic. It won't always get you good software in the sense of something that sells and is popular though. You would be purposely selling software that is likely to break with the next major release (or sooner) and relying on the consumer to be pro-active enough to upgrade it, and also not get mad at you for the initial "break."

Not everyone follows their favourite software developers blog, or is so involved in their tools that they want to be in a dialogue with the person who created them. Sometimes it seems that you folks are so wrapped up in "developer world" that you fail to see the forest for the trees.

mikeash - 2009-01-05 00:49:57

Mon, 05 Jan 2009 00:49:57 GMT

I think you overestimate the ability for developers to understand the purpose of Classic and be intelligent about how they develop.

A small but significant number of developers were still building code for Classic when it got axed, although I don't think any of them were building completely new apps for it. Classic was considered an acceptable solution by their customers and why bother learning something new when it works? Of course the answer is because it was going to go away, but not everybody realizes that.

In the modern world, processor architecture shouldn't affect very many people at all, and I view the people who got shafted by the removal of Carbon 64-bit as similar to the ones who got shafted when Classic disappeared. Apple could have been clearer about what they were doing, but the writing was still on the wall from way back.

David - 2009-01-05 00:02:41

Mon, 05 Jan 2009 00:02:41 GMT

Classic wasn't so much an API that you wrote to anyway, it was a technology that ran software that hadn't been updated since Mac OS 9 was a viable platform. As such, it wasn't there for developers, it was there for customers, and developers weren't really affected when it went away.

Historically, Apple obsoleted public APIs with that today would be considered wild abandon: QuickDraw GX, OpenDoc, AOCE, the list goes on. These days they only kill the big stuff, like entire processor architectures or promised 64-bit support for Carbon.

mikeash - 2009-01-04 11:01:57

Sun, 04 Jan 2009 11:01:57 GMT

I think I meant to say that Classic was available through 10.4. But it looks like I would have been wrong, or right, either way!

David - 2009-01-04 10:51:04

Sun, 04 Jan 2009 10:51:04 GMT

Sort of. Apple killed Classic halfway through 10.4's lifetime, so whether you had it depended on which type of machine you had (PPC or Intel).

As of 10.4.6 (the first Intel build), you could no longer rely on all customers having Classic available to them, so to a developer, you could say it was as good as dead at that point.

But that is splitting hairs. PPC builds kept classic through 10.4.11, and it wasn't until 10.5.0 that they lost it.

Steve - 2009-01-04 10:27:54

Sun, 04 Jan 2009 10:27:54 GMT

@Sean - nitpick: Classic was gone in 10.4 for Intel, which wasn't exactly a short term release before Leopard

;-)

Sean - 2009-01-04 09:34:37

Sun, 04 Jan 2009 09:34:37 GMT

nitpick: Classic disappeared in 10.5, not 10.4.