Xcode 4 public preview - Single window, LLVM 2.0, streamlined editing

So far as I know, the only way to get gcc (or any other compiler) initially onto a Mac is by accepting the entire Xcode package. I'm posting this here because you mentioned the 3GB download, which always makes me cringe. I'm curious to see if anyone knows a better way. (I've had this conversation online in a number of places in the last few years, but never received an alternative.)

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.

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.

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.

That's understandable. Most other IDEs handle GUI development by simply mashing the view and the controller together into a single unit. That is fine if you just have a simple window with some buttons and text fields, but this approach quickly falls apart when applied to larger, more sophisticated software.

The Cocoa approach is different in that it completely separates the view (the NIB or XIB) from the controller(s). You're free to design your views, controllers, models as you see fit, and Interface Builder is there to help you realize that design.

But you actually have to design your software; XCode is not going to hold your hand and shoehorn you into a specific design, like most other IDEs.

A NIB is still a NIB. That's not going to change just because XCode and IB are now a single application. You will still have to design your software, and you will have to understand that design.

But software design is hard, so don't be discouraged. It will come with experience.

I also can't speak highly enough about quickfixes. The ide presents me with a problem, and then makes it very easy to fix without having to think about all the crappy mechanics of doing so. If it's a common issue I can fix it all through my file, or all through my project. What is really amazing about this (as well as all the syntax-aware editing functionality) is that once you're good at it, you're no longer editing text, you're directly manipulating the AST at a very semantic level - and not just of a single file, but of your whole project. At the risk of gushing a little, this raised level of editing really contributes to my joy of programming because I'm actually directly manipulating turning my mental design into code. I would like to humbly suggest that people who say that you only need this functionality with crippled languages really don't know what they're missing out on.

Has this removed my ability to program Java in, say, Textmate or vi? No, although I'd have to re-learn so many basic, low level manipulation tasks that there's no way I could stand it. It doesn't remove my ability to develop using these editors, it removes my desire to.

With any (good) technology it becomes easier to do things and we gradually forget how to do the old, more complex way. I remember power going out at a big box (forgot which one) store once. None of the checkers had any idea how to figure out how much the items would cost by hand so the store was forced to simply not do business until power was restored. Was that embarrassing? Perhaps, but who cares? They can serve vastly more customers with the systems they have now than they ever could have with the old manual way.

With a big IDE you can manage vastly bigger projects quickly than you could with a text editor and a make file. You might point to the Linux kernel but most people who work on that just touch one area at a time [1]. With my big fancy IDE I can work on projects of at least that size and make big sweeping refactorings in seconds with complete confidence that nothing got missed.

[1] With the possible exception of Linus but if you're going to require that each of your devs be a Linus (or even that you have one for that matter) then you're probably not going to go far.

The problem is, C is a language where = vs == is actually something you have to think about. It's natural that IDEs arise to address this.

XCode is fixing what is really a problem at the language level. So it's the wrong place to fix the problem. At the same time, trying to fix the problem at the programmer level (by forcing programmers to check = vs ==) is equally the wrong place to fix it.

It's a language issue, and that's the place it really should be addressed. But it will never be addressed there, because it would break backwards compatibility since decades.

No official release date for the final release is known, but judging from Apple's history with developer previews you can expect it to be out within 6 weeks.

Can you bind shell scripts to the run button? Code folding?