Good for you - this is the way it should (and for most sane people, does) work. You ignore the tools until you understand what they're automating. One day, you'll get bored of writing boilerplate and trying to design the best UI by compile/run/repeat, and you'll go back to the tools for their appropriate uses.
It's always a benefit to understand exactly what's going on under the hood but I've seen some people take it too far, making this initial "I'm going to understand it properly" benefit into a curmudgeonly handicap^1. "I'm hardcore, I write all my UIs by hand! Those new fangled IDEs with their magic autocomplete - I keep my documentation on 430 sheets of fanfold printout! When I was young, we wrote all our code by hand using ed in Sanskrit, printed it out and hand soldered into hardware using tools we made by smelting our own iron!".
They're often right, to a degree - they can still write reasonable programs, and they'll likely have fewer defects than a person who just blindly uses tools. However, they often can't work in teams or adapt rapidly to new developments, and development change times are orders of magnitude above those who both understand the tools and when to use them.
1 - I'm not accusing the author of this problem, but the general tone does set a few alarm bells ringing...
XIBs are hardly magic. Make some UI objects in a XIB. They're just serialized to the XIB. "Outputs" are just fields with values. "Actions" are just objects and method names.
What this solves is that it's a pain to position UI elements with hand-coded coordinates. It also gets in the way of localizing the UI. You can't always just use the same UI in Germany where the words are longer. With XIBs, you just copy the XIB, resize the text boxes as necessary, and enter in the localized text.
I would agree, however, if you are writing a game then you wouldn't use XIBs. It's not because XIBs are magic (they're fairly straightforward) but because a game UI is nothing like the UI problem that XIBs were designed to solve.
This example does not even begin to describe what Interface Builder is good for. Why should I write any imperative code at all to set the font, font-size, text layout, subtle drop shadow, font-weight, font-style, etc. ?
In anything but the most trivial applications you will simply be wasting time not leveraging Interface Builder as well as generating pointless code.
Interface builder is the CSS of Cocoa development.
Of course he doesn't write a ton of shitty procedural client-side code to slowly build up the DOM programatically -- the browser gets a clean independent serialization, with bindings to code for events on elements. This is exactly how Cocoa works.
Interface Builder doesn't generate bolierplate code like nearly every other GUI designer ever to exist -- it instantiates objects and serializes them.
He doesn't like frameworks? Yeah, it only took Apple a decade and millions of dollars to make the framework, but I'm sure I can knock up something better in a week or two. While we're at it, why bother buying an operating system when we can just write a better one ourselves? Can't be that hard.
As a Cocoa developer, I can say that this is the stupidest stuff I've heard in a long time. I can't believe I'm reading it on the front page of hacker news.
I'm certain Apple has put a lot of hard work into the framework. As well as the operating system, etc. Your point is a good one, but let's please be civil here.
The article is interesting because I agree with a core concept of this rant, but the author's presentation fails to convince. The gem of the article is the last line "I can go about the business of making my own mistakes and learning from them; so that one day all of this might make sense." That is exactly how I feel about frameworks.
Sure, Apple put a lot of hard work into it, so that I don't have to. However, I'm going to have to put some hard work into something at some point. If I can't even understand the hard work in the underlying basics, how can I understand higher-level hard work?
[I suppose this isn't a reply to this specific article, but rather to the title and the whole idea of frameworks, macros, DSLs, code-generators and other such tools being "magic":]
A compiler is magic that turns your code into other code. Even if you say you have the source of the compiler, and can thereby figure out the magic, there's still more magic that created that magic in an infinitely-recursing chain, and it's very hard[1] to intuit beyond one step. What's the difference between using one of these tools, and writing in a modified language that has this "feature" the tool introduces, with a compiler that's aware of it? If there isn't one, then by saying you dislike magic, you're condemning every layer of abstraction we've built up above CPU microcode.
I can't be the only one. I'm faster overall in vi and xmonad with a browser window opened to the SDK docs than using arrow keys with code completion in XCode.
Interface Builder though, don't know how I lived without it when the first version of the SDK came out lacking it. shudder
Before someone says something about the xmonad thing and it sucking on the mac, I'm actually writing the code on a linux machine and building it on a mac via synergy :) Yes, it actually works pretty well!
It's always a benefit to understand exactly what's going on under the hood but I've seen some people take it too far, making this initial "I'm going to understand it properly" benefit into a curmudgeonly handicap^1. "I'm hardcore, I write all my UIs by hand! Those new fangled IDEs with their magic autocomplete - I keep my documentation on 430 sheets of fanfold printout! When I was young, we wrote all our code by hand using ed in Sanskrit, printed it out and hand soldered into hardware using tools we made by smelting our own iron!".
They're often right, to a degree - they can still write reasonable programs, and they'll likely have fewer defects than a person who just blindly uses tools. However, they often can't work in teams or adapt rapidly to new developments, and development change times are orders of magnitude above those who both understand the tools and when to use them.
1 - I'm not accusing the author of this problem, but the general tone does set a few alarm bells ringing...