I do have a question for the compiler geeks, though: how was LLVM able to so quickly surpass GCC in both compiling source and binary performance, considering gcc had a two decade head start?
While there's a lot of win in terms of code readibility and the great interfaces it exposes if you're going to write an IDE that understands the code, I'm not convinced it's there yet in terms of binary performance.
My apps run around 5%-15% slower, on average, than the GCC -march= setting.
I'm more interested in using LLVM on FreeBSD or Linux than on OS X, but I'm happy to see Apple pushing its development.
GCC isn't a particularly high bar to hit ICC and MSVC have been killing it for years.
It's largely the same reason that the ZFS codebase is drastically smaller than the UFS codebase. You don't think of the fastest / shortest way to do X the first time.
Not all the code works with LLVM, for example if you use LLVM to compile the linux kernel it won't boot.
FreeBSD however will actually compile and boot. http://wiki.freebsd.org/BuildingFreeBSDWithClang . It's not completely foolproof yet. I think the BSD community has welcomed LLVM a little more warmly than GNU/Linux.
The thing is that most compilers these days are limited by the performance of the CPU itself, as they're getting within a few percent of the best you can do.
I am curious as to what you don't like abou it?
- It's incredibly brittle. Good luck if you need to make significant changes to your hierarchy, or change that NSOutlineView of yours to an NSTableView. You'll have to rebuild and re-hook up all of the connections on an object. With no warnings or errors if anything is wrong. In HTML, you can just copy and paste, change some tags, and make some adjustments. Now HTML isn't ideal for application layout - but another markup language could be (MXML isn't bad).
- Doesn't play well with source control. Only one user can work on a .nib at once. Just yesterday another programmer and I both made changes to UI. Of course, it was completely unmergeable by machine or by hand - what do you expect when you have GUI generating a 7000-line file for relatively simple UI. So one of us had to re-do several hours of work. This isn't a problem with, say, HTML.
- Most significantly, it only solves a small part of the problem. It completely falls down when you're dealing with dynamic / variable UI - you'll have to resort to code anyway. And a lot of the layout you need to do is actually inside cells - say, trying to build a source list like iTunes, or a table view with icons inside of it. IB can't help here at all. Then, you end up laying out the actual UI in code. And what code it is:
NSDivideRect(cellFrame, &imageFrame, &textFrame, ICON_INSET_HORIZ + ICON_TEXT_SPACING + imageSize.width, NSMinXEdge);
imageFrame.origin.x += ICON_INSET_HORIZ;
imageFrame.size = imageSize;
textFrame.size.width -= ([self sizeOfBadge].width + ROW_RIGHT_MARGIN);
IB encourages you to use a very low level of abstraction. There's a lot of repetition, and the closed nature of the tool means it's very difficult to build up higher levels of abstraction. But then again, I guess Objective-C loves loves making programmers repeat themselves.
There's a reason most professionals don't use dreamweaver to make websites, either. And they are much the same.