@Karsten: Oh, that's clever. I've added your strategy to my workarounds stash. Peter Kamb pointed out yet another way to deal with the problem last night, by the way:

https://twitter.com/pkamb/status/334723713620656129

If you combine the info from all known workarounds, it's pretty obvious what/where the issue is. Now all we can do is vote for the bug to get fixed. You know, ROUYWF. (Radar or use your workaround forever.)

Where Apple is repeatedly going wrong is in thinking it can solve the traditional data silo problem by slapping on just another band-aid. That quick-n-dirty lash-up approach worked well for them over the years when it was just as case of replacing one local desktop platform (classic Mac OS) with another local desktop platform (OS X), so naturally their instinct is to use the same successful technique again.

But now they are trying to replace a local desktop platform with a highly distributed computing platform, which is not something that can be achieved simply by evolving the existing local computing idioms to make them magically distributed. It requires a complete ground-up rethink of how personal computing works. Which is not the single-sentence happy message that directors and shareholders want to hear, and so they continue pushing their old strategy into Peter Principle territory and beyond.

In addition to wanting a fast, cheap, simple [fantasy] solution to what is an unavoidably long, expensive, difficult and very real problem, Apple have a further COI polluting all their decisions. As a shamelessly commercial venture, Apple want to monetize every part of the user experience, which means they want to proprietize and control every part of the system. While that philosophy may work well for some things (by which I mean "puts lots of $$$ in vendor's pockets while keeping customers acceptably satisfied"), I think it is doomed to fail for any system on this scale.

Consider the Internet itself, which only succeeded once proprietary system vendors decided to set aside their own narrow controlling interests in order to achieve a broad common goal from which they would all subsequently reap some benefit (Game Theory 101). But Apple still want to control all their users' data, which means "their cloud, their way", rather than designing an open, flexible, forgiving system that provides everybody with the same freedoms. Look at the WWW, which has seen its original egalitarian principles (everyone can directly publish, everyone can directly share) eroded by commercial interests (only a small elite can directly publish, everyone else must either use their tollroads or just blindly consumer).

For cloud-based personal computing ever to work right, it has to be designed to be flexible and imperfect, trustworthy in its tolerance for faults, and respect the teeny tiny fact that user data should belong to the user, and it should be for them to define the rules by which it should be stored and shared.

A crude comparison would be to non-distributed vs distributed source control systems (e.g. Subversion/CVS vs Git/Mercurial). The former try to maintain absolute central control because that is 'simple' and 'foolproof', but all that happens is that users rebel: the system fails to meet their needs (e.g. see the horrors of resource locks and "Merge Day"), so they end up creating myriad ways to work around it, all bad. DVCSes share ownership and control across all users, and provide mechanisms for synchronizing differences and resolving disputes. Yes, it's an imperfect mechanism, but that's because it's designed to be. And, yes, martinets and OCD types will loathe it, but if you let those sorts run your lives then you deserve every ounce of misery they pour on you.

Obviously, there's still a considerable difference between how DVCS operates and what a full cloud system would need to do, like the difference between the world's first wheelbarrow and a modern Mack truck. But I think if you're going to look for inspiration then that is the place to start; whereas the old godlike mainframe data silo surrounded by myriad dumb terminals absolutely is not (and would be a disaster ready to happen).

Like I say, stuff is hard. And some things you can't pretend it's not.

As I recall, Lisp-style macros with M-expressions were an unsolved problem until the 90s (Dylan). It’s not at all clear to me that the syntax is what put people off Lisp.

As Larry Wall says: 'laziness is a virtue', but that must be qualified as 'correctly optimized laziness'. Far too many programmers would rather hammer out a thousand lines of code than stop to learn a new and alien technique that'd enable them to do it in a hundred. They're not lazy about writing code itself because they enjoy the code-writing activity for its own sake and would happily spend their whole lives doing it. They are often lazy about learning and disrupting the status quo though, because that isn't something they enjoy so much and distracts them from the coding which does.

As to my comparative example of Cocoa Bindings: it wasn't ahead when it came out 10 years ago, never mind now. It was _never_ designed with flexibility or scalability in mind, which is why it rapidly becomes hopelessly unwieldy and/or runs out of steam as soon as you start doing non-trivial stuff with it. Once again, it was optimized for the wrong results: ticking a marketing feature box and providing some quick shiny to customers who don't (yet) realize better. ObjC devs have been paying for this misdirected laziness ever since, and will eventually pay all over again when it finally gets thrown out and replaced with something completely different.

The whole C-derived cowboy hacker culture is like this: invest just enough time to whip together something that works (C language), then spend the next 40 years writing code that works around all its design deficiencies (shitty unhygenic macros; everything unsafe by default) rather than fixing those defects at source ASAP. The programming profession is often described as woefully ahistorical, which is true, but not only are they incredibly lazy about the past, they are also pathologically lazy about the future.

As someone who invests most of their meager brainpower finding ways to improve my base platform and toolchain precisely so as to minimize the amount of code I then have to produce (yuk), such a pervasively bass-ackwards culture is _very_ frustrating.

(Tho' ultimately I blame the Lispers, who were too lazy to slap a M-expression syntax on Lisp to make it palatable/attractive to the much larger Algol audience. Finest tool construction kit ever devised, totally ignored, unused and its lessons unlearnt - all for want of a cup o' sugar...)

[1] I think my opinions on the tightly coupled clusterfuck that Xcode's been turning into are already recorded, so won't rehash here. But there are plenty 3rd-party editors that prove the value of being flexible and extensible.

Cocoa Bindings is almost 10 years old now. Does Apple still think that its framework is ahead here?

Ugh. As a language ObjC has its place in Mac app development, but that should be limited to the Model, not the Controller or View. Why can't vendors like Apple and third-party devs just create some proper DSLs for the job? Or are modern developers so ossified in their "Everything now looks like an OO nail" mindset that they no longer possess such rudimentary tool-making and -using skills? Small task-specific languages are not hard to create, quick to learn, and much shorter and easier to read and write. I've written my own Scheme/Bash-like semi-declarative languages, and I've not had a CS lesson in my life. Proper talents like Rentzsch should be able to whack out something in a week and polish it to a lovely shine in a year or two.

I think there's an ongoing problem here regarding a lot of really interesting and potentially highly valuable idioms that mainstream OOP is starting to 'discover' in the non-OO spheres. FRP, which ought to blow away Cocoa Bindings and all the other old-school controller junk, is another recent example.[1] (And don't even get me started on the mess that's been made by idiots trying to OO-ify the web.) By the time such idioms have been sawed and hammered down to fit the orthodox imperative OO mold, they've shed all the conciseness and obfuscated most of the semantics or the original, and slapped reams of tedious boilerplate grunge onto what's left. Plus, of course, you lose all the other automatic benefits provided by the original declarative/functional platform, such as the ability to reason about behavior, give guarantees about side-effects, optimize repeated operations, etc.

It's no surprise that new technologies like MS's Reactive Extensions invite a backlash from folk who can't see what they offer over established native idioms other than a crapload of extra learning and some shiny new CV buzzwords. By the time such 'OO transformations' are done it is debatable that the remaining benefits significantly outweigh all the added costs.

[1] e.g. see: http://mjtsai.com/blog/2013/02/16/reactivecocoa-explanation

The WWDC videos on Auto Layout are the best introduction I've seen, though there are some books and third-party videos now I haven't looked at.

The only other system I've used that was anything like Auto Layout (not to say others don't exist!) was the Danger hiptop OS resource format. While there was a really horrible Java GUI editor for it, I usually edited it as text. Here's an example of Pester for hiptop:

http://dev.sabi.net/trac/dev/browser/trunk/hiptop/pester/locale/en_US/Pester.rsrc

You can see things like "alignWithParentTop" (the numbers are spacing amounts), "positionToRight" (of another control) or "alignBaseline" (my personal favorite, since so few layout tools have the concept of aligning text baselines of controls) which set up relationships between individual controls.