Auto Layout Shorthand

ALS is a (Wikipedia:) "debilitating disease with varied etiology characterized by rapidly progressive weakness, muscle atrophy and fasciculations, muscle spasticity, difficulty speaking (dysarthria), difficulty swallowing (dysphagia), and difficulty breathing (dyspnea)". (It's what Stephen Hawking has and some Lou Gehrig fellow apparently had.)

So yeah, that's a great acronym for a productivity hack. Although from what I'm seeing with Autolayout, gradually losing control and becoming stagnant for no good reason whatsoever certainly has some likeness to the process of debugging constraints.

I'm intrigued by autolayout. How does it compare to Tk's system of pack, grid and place?

Not much like the Tk system, really, which pretty much treats the controls as rectangles, and the layouts impose a structure on the controls. In autolayout, you set up a bunch of constraints about individual controls or relationships between pairs of controls, and the overall layout gets calculated; it's more of a bottom-up rather than top-down approach. So, for example, this object should be to the right of this other object, or stretch in this way. In IB, it suggests a bunch of default constraints so your buttons have the HIG-complaint spacing and so forth, even if they resize to accommodate localized text.

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.

Also, if there weren't so many weird connections in my brain between medical and computer acronyms, I wouldn't remember half the stuff I do. :-) So ALS it is.

Rentzsch: "a poor man’s DSL"

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

@has In this case, it seems like integrating a DSL with the other tools would be much harder than creating the DSL itself. At least the dictionary approach lets you have autocompletion, IDE renaming, and some compile-time checking.

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

@Michael: If your IDE won't take custom language modules, that's a reason to improve your IDE[1], not to not improve everything else. Otherwise nothing will _ever_ improve worth a damn.

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.

@has Yes, certainly the current Xcode situation makes DSLs more expensive and unwieldy. Even the extensible editors would have trouble checking that the identifier names match up with the code. Given that, I think Rentzsch’s approach here is sensible.

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.