waffle

Waffle is a weblog.
The author of Waffle, some guy in Sweden, also occasionally writes stmts.net.

Hard Core

Brent Simmons, who has written more Cocoa apps than you have, sold them to both more users and more companies than you have and spent more time implementing sync for them than all of their other features combined, just posted that he’s dropping Core Data for the syncing version of Vesper (no relation).

Core Data is a distant spritual successor of the long-gone NeXT-era EOF (Enterprise Objects Framework) project. While EOF dealt in object-relation mapping, Core Data is an object persistence layer and works with a variety of persistence stores, atomic or incremental, most of which are either SQLite or fools’ errands.

Quoth Brent, [original emphasis]

So now I’m not using Core Data with Vesper. I hope the people who (quite rightly) like Core Data are not disappointed. I like Core Data too and recommend it.

Consider the below not as criticism of Core Data but as a description of what I personally like. Also consider all the things I’m giving up: faulting, NSFetchedResultsController, the Core Data modeler (I’m using a plist instead), and plenty more.

Brent is clearly happy with Core Data. But he’s also clearly not using it, after wrangling with it for a while. I’ve beta tested several versions of NetNewsWire over the years when Brent developed it and I’ve been hearing Brent thinking out loud on this subject on the beta discussion list for many previous rounds. It’s not the first time Core Data’s been considered heavily, including development, and dropped. (It did make it into some NetNewsWire versions, including NetNewsWire Lite 4.0.) But Brent has detailed his propensity to create things which have the “mark all as read” problem, which is a tall order for an object database: having to materialize the object out of the store just to flip a flag and save all of it back.

So maybe Brent is just a walking pathological scenario. Let’s try someone with even more experience: Delicious Library author Wil Shipley, who’s been writing Cocoa since NeXTStep 0.8x in the 1980s and who knew Craig Federighi when he was on the EOF team. Even Wil’s been fighting Core Data. Not the hard parts. The easy parts. The ones where you get stuff for free and it’s supposed to just work.

Which reminds me: Core Data is also a supported engine for iCloud syncing. It’s supposed to be no more complex than just using Core Data on its own, so imagine everyone’s surprise when it was just as complex as using Core Data on its own. Uncountable apps made the tentative move to iCloud Core Data, and most receded painfully after endless complaints. Apple supposedly made amends and encouraged everyone to “try again”. I’m not sure if that silence you’re hearing is the sound of everything working fine or the sound of no one jumping at the chance to go through that again.

Of Apple’s fixes’ own admission, Core Data sync didn’t work because it was a black box with no ability to debug it. It would be unfair to zing Core Data at large with that epithet. But if it’s something that seems true about Apple’s frameworks, love them mostly as I do, it’s that they’re constructed as if to impress on their user how privileged they should feel because of the difficulty of the bar that they set to solve the problem at, and the complexity of implementation they have used to convincingly solve the problem.

Or to put it another way: Cocoa is so very prone to have heroic solutions that require you unerringly to write heroic or at least merely mistake-less code.

Key-Value Observing. Cocoa Bindings. Retain/release. The thing they invented – ARC – to solve retain/release. Weak referencing self in blocks or creating memory leaks. Auto layout. I consider myself a decent programmer, but I try to work out the complexity involved in completely implementing all-frills NSDocument loading and saving and I get winded. There are operating system kernels with lower cyclomatic complexity.

It’s true; other platforms do suffer from not having quite a few elegant solutions present in Cocoa. (Oh, to have every object solve key-based archiving/coding abstractly, so that you can get universal coverage with your own serialization engine; NSCoding is the most underappreciated piece of design in all of Cocoa.) And it is very neat when it all works. But what about when it doesn’t? What is the cost of demanding if not eternal vigilance, then at least that a fair chunk of your cycles go toward keeping your code at the level demanded by your harsh mistress?

All platforms demand the ability to walk and chew bubblegum at the same time, because nothing’s ever free and most things that are worthwhile won’t be trivial. The role of Cocoa shouldn’t be to appeal to the lowest common denominator. But it has a steeper learning curve than almost any other platform other than idiomatic C++.

There’s nothing inherent about Objective-C that makes complexity come to the fore. The community doesn’t have any problems creating simple frameworks that solve problems. Indeed, it’s interesting how the most popular code seems to be conveniences that sidestep problems in the frameworks as well as alternative frameworks that do less than the Apple-provided frameworks. Less.

I get it. Apple, and NeXT previously, rolls. The baton is passed on, forever, in the name of not reinventing something.

It’s always easy to demand a revolution (and with all this civil unrest, ’tis the season). It’s doubly easy for the guy who thought Apple were working on a new language to want some variant of that to come to fruition after an increasingly embarrassing number of years.

And yes, it’s way too easy to blame the frameworks and the platforms, and to conclude in the reverse that the existence of alternatives does not cast shadows on the things that they are alternatives to.

To all this: OK, sure. But what about the pain? Basic features are still painful for people that have been successful Cocoa coders for ten years. They’re not sufficiently saved by the ripening of frameworks as much as by their own accumulated ingenuity. Cocoa is still being developed, features are added, but rarely does something hard get easier.

Two codas: Brent’s commentary and objc.io issue 10, which is all about syncing and Core Data, rife with stories from the field.

Comments

  1. I have two thoughts that might be relevant to some of this angst:

    Expectations are high. Users have come to expect a certain suite of features in mainstream apps. These expectations are completely unhooked from, and ignorant to the difficulty level involved in actually implementing those features. In this vein, my favorite poster child feature is autosave. People pitch a fit if you have a document-based app that doesn’t do auto-save. The Cocoa frameworks provide a lot of underpinnings that can get a trivial app (i.e. one whose documents aren’t large or complex) a long way toward autosave “for free”. But, as soon as your persistence story is any more complex than “use NSCoding to serialize a small object model to an NSData and hand it off” (usually when the performance of that approach takes too long to do on the main thread) you’ve got to do some real, non-trivial, hard work, in some non-trivial, or to use your word, “heroic”, APIs to deliver a feature without which, your users will look upon you with incredulity, as if to say, “No Autosave? What is this? 1995?”

    What makes this even harder to swallow, are the dog & pony shows, and the sample code. You go to WWDC, and some smart guy stands up on stage and walks you through producing a document-based app with autosave in 20 minutes and 25 lines of code. This talk will be punctuated with comments like “See how easy this is?”, “It just works!”, or “The frameworks do everything for you!” Sometimes I feel like the frameworks are designed specifically to facilitate these sorts of talks, because, yeah: if you want to produce something just as simple and straightforward as what the WWDC guy produced, the frameworks do everything for you in 25 lines of code.

    The net result is that you get home from dub-dub and you go to work with some of these new features in your app, and lo and behold it turns out to be hard because your app isn’t trivial like the guy on stage’s app is. But what’s even worse, is that now you feel like a dumb-ass because this guy you just paid thousands to hear talk told you how easy and simple it was, and he produced this whole app in 25 minutes, and it looked easy, and you can’t replicate that success in your app. Let’s call it the, “Am I doing something wrong here or what?!” moment.

    With that in mind, I think it’s perfectly justified to be angsty. I think at the end of it all, it boils down to “complex apps are hard work” and “the PR machine kinda lies to you and tells you that writing complex apps is easy.”

    By Jour · 2014.03.19 22:09

  2. That. Exactly that.

    By Jesper · 2014.03.21 20:03

Sorry, the comment form is closed at this time.